Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Standardisation of Code Structure and Naming #28

Open
JGarciaCondado opened this issue Apr 9, 2024 · 1 comment
Open

Standardisation of Code Structure and Naming #28

JGarciaCondado opened this issue Apr 9, 2024 · 1 comment
Labels
documentation Improvements or additions to documentation refactoring Code refactoring
Milestone

Comments

@JGarciaCondado
Copy link
Contributor

JGarciaCondado commented Apr 9, 2024

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.
@JGarciaCondado JGarciaCondado added enhancement New feature or request refactoring Code refactoring documentation Improvements or additions to documentation and removed enhancement New feature or request labels Apr 9, 2024
@JGarciaCondado
Copy link
Contributor Author

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?

@JGarciaCondado JGarciaCondado added this to the Release 1.0 milestone Apr 15, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation Improvements or additions to documentation refactoring Code refactoring
Projects
None yet
Development

No branches or pull requests

1 participant