12.1. Coding practices

12.1.1. Environment

We use Python 3.6+ and exploit its features. Developers are encouraged to use the Miniconda 64-bit environment. You can create a new development environment by using the environment.yml file located in the project root, type conda env create --file environment.yml. This will create a new dedicated Conda environment named cate-env.

(In order to generate Cate’s documentation we use a simplified version of the environment environment-rtd.yml in the ReadTheDocs (RDT) configuration, see Docs on ReadTheDocs.)

Don’t use any platform-specific features of Python!

12.1.2. Testing

  • Write good tests. Good tests are ones that test expected core behaviour. Bad tests make it hard to refactor production code towards better architecture. See article Why Most Unit Testing is Waste. Thanks, Ralf!
  • Target at 100% code coverage to make sure we don’t access inexistent attributes, at least for a given test context. But remember that 100% code coverage does not imply 100% coverage of the possible configuration permutations (which can be close to infinity). Therefore it is still the quality of tests that provide value to the software and that result in high code coverage.
  • Use pytest for testing, to run test with coverage type pytest --cov=cate test

12.1.3. Git

  • Not push any code to master that isn’t backed by one or more unit-tests.
  • Keep master unbroken, only push if all test are green.
  • Always create new branches for new experimental API or API revisions. Don’t do that on master. Merge when branch is ready and reviewed and accepted by the team. Then delete your (remote) branch.
  • When working in the official repository, there is a guideline for branch names. Use issuenr-initials-description.