Coding Guidelines for Developers

Coding style

Maintaining proper coding style is very important for any larger project for a number of reasons:

  • It eases maintenance.
  • It allows better understanding of the code for unfamiliar users.
  • It allows easy review and debugging of the code.
  • It makes the code more aesthetically pleasing.

The coding style conventions described in this post are not optional and all Rupture developers should follow them. This post will be updated with new guidelines as the project evolves.

General conventions

  • Use space-expanded tab that equals 4 spaces.
  • Avoid trailing whitespaces and empty lines at the end of files.
  • Max line length of 80 characters is not mandatory, but should be preferred anywhere possible.
  • Use descriptive names for variables, functions and classes.
  • Comments should be indent together with the code.
  • Inline comments should be avoided in general. Use block comments instead.
  • Do not use hardcoded values. That's what configuration files are for.
  • Use logging, not print statements.
  • Do not commit commented out code fragments. If there is a really good reason, use if statement with descriptive conditions.


Please follow the PEP 8 guidelines, unless they are in conflict with guidelines described in this post.


Follow the conventions used in the community. A good guide on Javascript style can be found here.

Source code management (Git)

Rupture uses git to maintain all code, so before contributing to the project make sure to understand its functionality. A good introductory book on git can be found here.

  • Commits should be short and descriptive. Code blocks that add different functionality should be commited in different commits.
  • Commit messages should be short and descriptive. Use imperative present tense. The summary line should be less than 50 characters and description paragraphs should be included where necessary.
  • Do not rewrite published history.
  • Rupture code is centralized on the main Github repository.
  • Do not push on master/develop branches. Use feature branches for each change and pull request on develop.
  • Make sure the feature code passes all tests.