The MFAssignR package was designed for multi-element molecular formula (MF) assignment of ultrahigh resolution mass spectrometry measurements. A number of tools for internal mass recalibration, MF assignment, signal-to-noise evaluation, and unambiguous formula selections are provided.
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.
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.
The lines are an if ... else block which could be nicely refactored into 3 functions, one for each branch of the condition and one for the whole thing. I also think maybe some parts of the implementation can be shared to make the if ... else part smaller.
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 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.
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.
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.
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.
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.
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/