Project maintained by pytroll Hosted on GitHub Pages — Theme by mattgraham

Pytroll coding guidelines and best practices

“It is not the strongest of the species that survives, nor the most intelligent that survives. It is the one that is most adaptable to change.” —Charles Darwin

“It seems that perfection is attained, not when there is nothing more to add, but when there is nothing more to take away.” —Antoine de Saint Exupéry

Coding Style

Maintainability Guidelines

Style Checking

In your IDE/editor, it is highly recommended to activate/install a plugin for/script a save hook for doing automatic style checks and/or corrections, eg autopep8, pylint, pyflakes. Most repositories will use the “stickler” github bot to automatically check pull requests for PEP8 with the flake8 tool.

Working with Github

Before submitting your changes, make sure your code follow the coding style above, and that your changes are properly covered by tests and documented. Make sure you run a style checker (eg pylint) on your code.

If you want to help develop a Pytroll package, the preferred way to contribute is to fork the original repository and submit a pull request with your proposed changes.

The workflow in a nutshell is to:

Pull requests should avoid committing or adding unused files (ex. .pyc files). Even if they are deleted in future commits they should be purged from the commit history. See this github article for instructions.

Alternatively, patches formatted with the git format-patch command can be sent to the bdfl of the package.

The submitted work will be reviewed by the main contributors of the package, possibly engaging in a discussion on the patch, and maybe requesting changes. Be prepared to follow up on your work.

Commit messages:

Making releases

“Release early, release often”

Versioning: SemVer

The procedure for releasing should be provided in each repository in a or similarly named file.

Appendix A

PEP 20: The Zen of Python