Contribution Guidelines

To make sure the code in this project remains consistent over the multiple modules, we require contributors to follow the recommendations below.

• Class names should be CamelCase. For example:

class MyNewClass

• Additionally, constants should have each of its words capitalized, linked by an underscore:

MY_NEW_CONSTANT = 10

• Everything else should be named using snake case:

my_new_variable = some_function()

• Each line in the code should not exceed 80 characters. The goal is to promote readability. Therefore, it is OK to exceed a little 80 characters if this will make the code more readable.
• Use 4-Character indentation. NEVER use tabs.
• The length of the functions should reflect their complexity. It is OK to have long functions if they very simple. Complex functions, however, should be very small. Ideally, keep functions small.
• Try to avoid loops as much as possible
• Avoid code repetition
• Handle all exceptions and use proper exceptions and not Exception for everything
• Do not create a Christmas tree of try: except: blocks
• Teams willing to contribute features should name their feature branches with team/<team-name>/feature/<feature-name>. For example, if a team called my-team wants to create a new feature called my-new-feature, then he should name his feature branch team/my-team/feature/my-new-feature. Prefer separating words with hifens.
• While merging, use the --no-ff option. For example, to merge the branch my-team/feature/my-new-feature use:

git merge --no-ff my-team/feature/my-new-feature

• To create a new contribution, make a pull request to the develop branch. While not 100% enforced, we follow many of the ideas of the git-flow branching style. That is why we like branch names like feature/... (or, if coming from a fork, team/myteam/feature/...) and merge branches in the develop branch.

These are actually our adapted version (without some things that we didn't like) of the Google guidelines. You can take a look at their recommendations here.