recetox / mfassignr Goto Github PK

• Reformat the code
• Implement a unit test for the function
• Include parameters in the unit test

• Reformat the HistNoise module code
• Add unit test using https://usethis.r-lib.org/reference/use_r.html
• Implement a unit test using the data coming with the package

Create a small example on how to call the KMDNoise estimation function with tabular peak data (multiple samples) and how to apply the estimated level as a filter.

• Build and test the R package using the recommended GitHub CI pipeline
• Enable Codecov coverage report automation

See https://github.com/RECETOX/recetox-aplcms as an example

Logic related to halogen compounds should be investigated to see which atoms are support and what kind of functionality is implemented to see what needs to be extended.

Create a bioconda recipe for the package and submit it to bioconda to make the package available in Galaxy.

A guide on how to create bioconda recipes is available here.

Grayksull is agood utility for bioconda recipes: https://github.com/conda/grayskull

Test for a module can be added easily via command line using this library: https://usethis.r-lib.org/reference/use_r.html

• Reformat module
• Implement unit test for the Recal function
• Implement unit test for the RecalList function

This needs to be done to create the bioconda package and should be done after fixing and re-arranging the package structure.

These are separate modules but it isn't obvious what is the difference or when we should use which one - do these operate in a different mode or? This would be crucial to understand before starting with the Galaxy wrapper.

• Apply formatting
• Rename variables to have matching names
• Pull out constants and put them into global variables with matching names in a first step
• Extract code into functions where possible

KMDNoise line 166 re-defines the SNplot function which is also defined in HistNoise. One of the implementations should be removed if they are not actually different.

Follow the standard refactoring procedure - understand the code, extract functions, put constants into variables, make the code nice to read and easy to understand and test.

As the function is really long and the code is hard to read, the function should be refactored so that it also becomes easier to re-use code and extend the module in the future.

It also seems that some code from the IsoFiltR is copy-pasted in the MFAssignCHO module, so it is worth checking where code was potentially taken from or whether some steps might already be contained in other functions.

• KMDNoise
• IsoFiltr
• #9
• #10
• #11

The columns should be expected but not in a set order of things.

Follow the standard refactoring procedure - understand the code, extract functions, put constants into variables, make the code nice to read and easy to understand and test.

These modules are responsible for formula annotation and might share some code or concepts. It would be important to figure whether

• MFAssignCHO is a special case of MFAssign
• code is shared across the modules
• one function calls the other one?

More things which we should look at should be discussed.

The overall structure of the repository should be adapted so that it follows the guidelines and best practices for R packages which are detailed here: https://r-pkgs.org/

The IsoFiltR module has some magic numbers that don't seem to have an explanation. There is some dissteration available (TODO: provide link) which contains information of those numbers. Otherwise, explanation might be somewhere in the paper but it doesn't seem so at this point.