You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Although efforts have been made to have clear code and more structured code this can be improved.
Improvements should focus in standardising how/when self is called, what inputs and outputs different functions have (especially looking at the interface object where each method seems to be doing their own thing). Naming conventions should be established.
In terms of code clarity:
What are the conventions for different objects and functions? what should appear in docstrings (description, I/p and o/p), which are public/private including naming, parameters and returns well defined (typing and specific exceptions).
Order of imports and methods within classes. What are we following?
Naming conventions for Objects and Functions
In terms of messaging:
A verbose flag should be added to all commands to not show print outputs
Do we still need warnings if we are printing already messages?
In help messages of commands all information should be informative and displayed in the same way. All defaults should be clear.
Help in interactive CLI should show more information like how files should be structured.
Ensure that all string follow the same are we using f strings or %s?
In terms of structure:
We should reconsider how the software package works and different objects interact with each other. Maybe a UML structure diagram could help.
Do we need a function called setup and command_setup?
In interface object the i/p and o/p of methods should be standardise. Some have dataframes others have numpy arrays. Some make use of self others don't. As well, where is covariate correction called in the higher level methods or lower.
Maybe the interactive cli we have should be separate to the interface object like the commands.py
Should all print statements be confined to the Interface object? I.e. remove in the AgeML object the prints and instead return the metrics so that it can be used better as sklearn is used in python.
A strategy could be followed where AgeML behaves like an sklearn library. That AgeML objects returns metrics when calling AgeML.scores() and that that naming of method follows sklearn like .fit(), .cross_val_predict(). This should be the same for the classifier.
Requirements to close the issue:
Clear structure and documentation of the software development practices
Ensuring all code has been reformatted to the standards.
The text was updated successfully, but these errors were encountered:
I guess also another standardisation that should be thought of would be the files and their format. For example, in the clinical file we are using TRUE and FALSE. Maybe we should use 0 and 1 which are used more commonly?
Although efforts have been made to have clear code and more structured code this can be improved.
Improvements should focus in standardising how/when self is called, what inputs and outputs different functions have (especially looking at the interface object where each method seems to be doing their own thing). Naming conventions should be established.
In terms of code clarity:
In terms of messaging:
In terms of structure:
We should reconsider how the software package works and different objects interact with each other. Maybe a UML structure diagram could help.
Requirements to close the issue:
The text was updated successfully, but these errors were encountered: