REGISTER NOW: Brightway Spring School! 🇨🇦 Québec City (Canada) 🗓️ 20.-24. May 2024

Contributing to the Code#

If you would like to contribute to the development of Brightway, follow the usual GitHub process: Fork the relevant Brightway repository on GitHub, make your changes and open a pull request with your changes.

Note

The Brightway project has adopted the Contributor Covenant.

See also

The development of major new features, collecting community input on issues, and documenting Brightway design decisions is managed through Brightway Enhancement Proposals[1].

Specific Guidelines#

Code Style#

Brightway has currently not adopted a specific code style beyond Python PEP8. However, we recommend the use of Black to ensure a consistent code style across the code base.

Docstrings#

Warning

The use of descriptive docstrings for all Brightway functions, classes and class methods is mandatory. Brightway has adopted the NumPy Docstring Style.

Writing code that is easy to understand is a key principle of Brightway. This is why it is not enough to write code with descriptive variable names and comments. All functions, classes and class methods must be documented with a docstring. These docstrings are used to automatically generate the Brightway API documentation. As such, they should form the basis of the documentation of the Brightway code base.

Using the full extend of the NumPy Docstring features, including the Examples, Raises, See Also, Notes, and References sections, is recommended:

Docstring Features

Feature

Required

Comment

short summary

yes

N/A

extended summary

yes

N/A

attributes

yes

N/A

parameters

yes

must include types

returns

yes

must be Nothing the function does not return anything

raises

yes

N/A

see also

optional

should like to other relevant functions

notes

optional

scientific/mathematical explanation of the life-cycle assessment functionality

references

optional

references for the information used in notes

examples

yes

mandatory for all public functions, classes and class methods

The __init__ method should be documented as a docstring on the init method itself. This means that The attributes and parameters sections will be split between the class docstring the the __init__ docstring.