Coding standards and best practices
We follow these practices when developing RapidSMS code:
- Work on a branch off the develop branch.
- Follow PEP8 style conventions.
Use 4 spaces instead of tabs.
- Run the PEP 8 adherence tool.
- Use CapitalizedCase for class names, underscored_words for method names.
- Code using os.path must be Windows and ‘NIX friendly. For example,
don’t use backslashes (\) as path separators.
- Be sure every class and method has docstrings.
- Use Python logging whenever an error or exception occurs.
Optionally include debug-level logging.
- Write a test
which shows that the bug was fixed or that the feature works as expected.
- Run the RapidSMS core test suite to make sure nothing unexpected
broke. We only accept pull requests with passing tests.
- Write new or update existing documentation
to describe the changes you made.
- Add the change to the release notes
document for the next release. The release notes should focus on the effects
on existing users, particularly if it will require them to make changes.
- Submit a pull request
and get reviews before merging your changes, even if you have authority to
merge the changes yourself.
- Sign the
Contributor License Agreement.