-
magicfelix authoredmagicfelix authored
Development principles and contribution guidelines
In order to create a high-quality software product, the AlekSIS developers have agreed upon fundamental principles governing the code layout, coding style and repository management for AlekSIS and all official apps.
Coding layout and style
The coding style is defined in PEP 8, with the following differences and decisions:
-
The defaults of the black code formatter are used - This implies all string literals usin double-quotes, if it does not lead
to more escaping. As proposed by black: "My recommendation here is to keep using whatever is faster to type and let Black handle the transformation."
-
The maximum line length is 100 characters
-
Imports are structured in five blocks, each of them sorted as defined in PEP 8 and the Django style guide:
- Standard library imports
- Django imports
- Third-party imports
- Imports from AlekSIS core and other apps (absolute imports)
- Imports from the same AlekSIS app (realtive imports)
Use isort to take care of this
For the layout of source trees and style recommendations specific to Django, the Django coding style is a good source of information, together with the Django Best Practices collection.
To ensure code is styled correctly, before commiting, run:
tox -e reformat
Text documents
If there is no objective reason against it, all text documents accompanying the source use reStructuredText.
Working with the Git repository
The Git repository shall be used as a historic documentation of development and as change management. It is important that the Git commit history describes what was changed, by whom and why.
Help and information on Git for beginners are available in the Git guide
Feature and issue branches
All features and bug fixes should be developed in their own branch and later merged into the master branch as a whole. Of course, sometimes, it is sensible to not do that, e.g. for fixing mere typos and the like.
Within the feature branch, every logical step should be commited separately. It is neither required nor desired to do micro-commits about every development step. The commit history should describe the trains of thought the design and implementation is based on.