The following is a set of guidelines for contributing to pyrfu and its packages, which are hosted on GitHub. These are mostly guidelines, not rules. Use your best judgment, and feel free to propose changes to this document in a pull request.
This guide defines the conventions for writing Python code for pyrfu.
The main ideas are:
- ensuring a consistent code style
- promote good practices for testing
- maintaining a good level of readability and maintainability
- to keep it simple
Prefer if possible Python>=3.8 since there are major dependencies that do not support older python versions.
The pyrfu package uses the Black code style .
Linters are tools for static code quality checker. For instance, you can use the following tools to test conformity with the common pythonic standards:
- pylint is one of the oldest linters and tracks various problems such as good practice violation, coding standard violation, or programming issues. Pylint may be seen as slow, too verbose and complex to configure to get it working properly. You can run a complete static analysis with the following command:
pylint pyrfu --rcfile=setup.cfgAll these linters can be simply installed with pip. Further details on the functionnalities can be found here or there. Also, a lot of features can also be provided natively or by installing plugins with your IDE (PyCharm, Spyder, Eclipse, etc.).
To be accepted to pyrfu every new code as to get a pylint score of 10/10.
Documentation of all the files must be done in-line using Sphinx. The doxtring as to follow the numpydoc style