This section contains some code style guidelines for the different programming languages used in the project.
Follow PEP 8, the linting tools below can find PEP 8 problems for you automatically.
All public modules, functions, classes, and methods should normally have docstrings. See PEP 257 for general advice on how to write docstrings (although we don’t write module docstrings that describe every object exported by the module).
pep257 tool (which is run by
prospector, see below) can point out
PEP 257 violations for you.
It’s good to use Sphinx references in docstrings because they can be syntax highlighted and hyperlinked when the docstrings are extracted by Sphinx into HTML documentation, and because Sphinx can print warnings for references that are no longer correct:
- Use Sphinx info field lists to document parameters, return values and exceptions that might be raised.
- You can also use reStructuredText to add markup (bold, code samples, lists, etc) to docstrings.
We use Flake8 for linting Python code.
Lint checks are run as part of our continuous integration builds and can be run
make lint. You may find it helpful to use a flake8 plugin for
your editor to get live feedback as you make changes.
Automated code formatting¶
You can use YAPF (along with the YAPF configuration in this git repo) to automatically reformat Python code. We don’t strictly adhere to YAPF-generated formatting but it can be a useful convenience.
We use ESLint for linting front-end code. Use
lint to run ESlint locally. You may find it helpful to install an ESLint
plugin for your editor to get live feedback as you make changes.