Developer Notes¶
Here we gather important notes for the developing of oemof and elements within the framework.
Collaboration¶
We use the collaboration features from Github, see https://github.com/oemof.
Style guidelines¶
We mostly follow standard guidelines instead of developing own rules.
PEP8 (Python Style Guide)¶
- We adhere to PEP8 for any code produced in the framework.
- We use pylint to check your code. Pylint is integrated in many IDEs and Editors. Check here or ask the maintainer of your IDE or Editor
- Some IDEs have pep8 checkers, which are very helpful, especially for python beginners.
Quoted strings¶
For strings we use double quotes if possible.
info_msg = "We use double quotes for strings"
info_msg = 'This is a string where we need to use "single" quotes'
Naming Conventions¶
- We use plural in the code for modules if there is possibly more than one child class (e.g. import transformers AND NOT transformer). If there are arrays in the code that contain multiple elements they have to be named in plural (e.g. transformers = [T1, T2,...]).
- Please, follow the naming conventions of pylint
- Use talking names
- Variables/Objects: Name it after the data they describe (power_line, wind_speed)
- Functions/Method: Name it after what they do: use verbs (get_wind_speed, set_parameter)
Using git¶
Branching model¶
So far we adhere mostly to the git branching model by Vincent Driessen.
The only difference is to use a different name for the branch origin/develop (“main branch where the source code of HEAD always reflects a state with the latest delivered development changes for the next release. Some would call this the integration branch.”). The name we use is origin/dev.
Issue-Management¶
Section about workflow for issues is still missing (when to assign an issue with what kind of tracker to whom etc.).