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 backend-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¶
Hypothesis projects use Black for automated
code formatting. Formatting is checked as part of continuous integration builds
and can be run locally using
make format. You may find it helpful to use
a Black plugin for your editor to enable automated formatting as you work.
- Although we don’t strictly follow all of it, the Google Python Style Guide contains a lot of good advice.
We use ESLint for linting front-end code.
make frontend-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