Style Guidelines

This page describes the style guidelines we'll try to adhere to for find_differential_primers.

Project Style

We will adhere as closely as possible to PEP8 Python guidelines (though we can relax the maximum line length). This will maximise readability and help ensure consistency of style over several projects.
We will follow PEP257 for docstrings.
We should pay attention to pylint/flake8 suggestions of code quality, especially regarding the complexity of code (e.g. function length, numbers of arguments). There are Pythonic ways to code that accommodate these suggestions (e.g. namedtuples for related collections of values that can be passed as a single argument), and they are good practice.
We will use nosetests as our test framework, and these tests will be run as part of our continuous integration practice.

Code quality checks should be implemented in pre-commit git hooks. One of these is included in the repository, and should be enabled in each local repository by issuing the following commands from the repository root:

mkdir -p .git/hooks
cp git_hooks/pre-commit ./git/hooks

We will also use the landscape.io service when it comes back online to have a public, badged statement of code quality.

All development should take place under a branch that is based in the diagnostic_primers branch.
There should be a separate branch for each conceptual unit of development (the nature of a conceptual unit is flexible, but extensive modifications across large parts of the code base are to be avoided in a single branch).
Commits should be atomic, as far as is possible.
The development cycle should follow the pattern:
- branch from diagnostic_primers (git checkout -b <branch_name>)
- make changes, using atomic commits
- push to the GitHub repo often (it's our backup!)
- when complete, issue a pull request, and assign another developer to let them know there is code available
- the assigned developer will inspect the code and, if tests are passing at Travis-CI, and there are no other warning signs, the PR should be merged.

Ideally, new code should be completely covered by tests, but in practice we are likely only to achieve partial coverage.
PRs should not be accepted if the changes are not covered by tests.