— The Zen of Python, Tim Peters
It's easy to let readability and coding standards fall by the wayside when a software project moves into "maintenance mode." (It's also easy to never establish those standards in the first place.) But maintaining consistent style and testing standards across a codebase is an important part of decreasing the maintenance burden, ensuring that future developers are able to quickly grok what's happening in a new-to-them project and safeguarding the health of the app over time.
A great way to protect the future maintainability of a project is to use external libraries to check your code health for you. These are a few of our favorite libraries for linting code (checking for PEP 8 and other style errors), enforcing a consistent style, and ensuring acceptable test coverage as a project reaches maturity.
Check your code style
PEP 8 is the Python code style guide, and it sets out rules for things like line length, indentation, multi-line expressions, and naming conventions. Your team might also have your own style rules that differ slightly from PEP 8. The goal of any code style guide is to enforce consistent standards across a codebase to make it more readable, and thus more maintainable. Here are three libraries to help prettify your code.
Pylint is a library that checks for PEP 8 style violations and common errors. It integrates well with several popular editors and IDEs and can also be run from the command line.
To install, run
pip install pylint.
To use Pylint from the command line, run
pylint [options] path/to/dir or
pylint [options] path/to/module.py. Pylint will output warnings about style violations and other errors to the console.
You can customize what errors Pylint checks for with a configuration file called
Flake8 is a "Python tool that glues together PEP8, Pyflakes (similar to Pylint), McCabe (code complexity checker), and third-party plugins to check the style and quality of some Python code."
To use Flake8, run
pip install flake8. Then run
flake8 [options] path/to/dir or
flake8 [options] path/to/module.py to see its errors and warnings.
Like Pylint, Flake8 permits some customization for what it checks for with a configuration file. It has very clear docs, including some on useful commit hooks to automatically check your code as part of your development workflow.
Flake8 integrates with popular editors and IDEs, but those instructions generally aren't found in the docs. To integrate Flake8 with your favorite editor or IDE, search online for plugins (for example, Flake8 plugin for Sublime Text).
Isort is a library that sorts your imports alphabetically and breaks them up into appropriate sections (e.g., standard library imports, third-party library imports, imports from your own project, etc.). This increases readability and makes it easier to locate imports if you have a lot of them in your module.
Install isort with
pip install isort, and run it with
isort path/to/module.py. More configuration options are in the documentation. For example, you can configure how isort handles multi-line imports from one library in an
Like Flake8 and Pylint, isort also provides plugins that integrate it with popular editors and IDEs.
Outsource your code style
Remembering to run linters manually from the command line for each file you change is a pain, and you might not like how a particular plugin behaves with your IDE. Also, your colleagues might prefer different linters or might not have plugins for their favorite editors, or you might be less meticulous about always running the linter and correcting the warnings. Over time, the codebase you all share will get messy and harder to read.
A great solution is to use a library that automatically reformats your code into something that passes PEP 8 for you. The three libraries we recommend all have different levels of customization and different defaults for how they format code. Some of these are more opinionated than others, so like with Pylint and Flake8, you'll want to test these out to see which offers the customizations you can't live without… and the unchangeable defaults you can live with.
Autopep8 automatically formats the code in the module you specify. It will re-indent lines, fix indentation, remove extraneous whitespace, and refactor common comparison mistakes (like with booleans and
None). See a full list of corrections in the docs.
To install, run
pip install --upgrade autopep8. To reformat code in place, run
autopep8 --in-place --aggressive --aggressive <filename>. The
aggressive flags (and the number of them) indicate how much control you want to give autopep8 over your code style. Read more about aggressive options.
Yapf is yet another option for reformatting code that comes with its own list of configuration options. It differs from autopep8 in that it doesn't just address PEP 8 violations. It also reformats code that doesn't violate PEP 8 specifically but isn't styled consistently or could be formatted better for readability.
To install, run
pip install yapf. To reformat code, run,
yapf [options] path/to/dir or
yapf [options] path/to/module.py. There is also a full list of customization options.
Black is the new kid on the block for linters that reformat code in place. It's similar to autopep8 and Yapf, but way more opinionated. It has very few options for customization, which is kind of the point. The idea is that you shouldn't have to make decisions about code style; the only decision to make is to let Black decide for you. You can read about limited customization options and instructions on storing them in a configuration file.
Black requires Python 3.6+ but can format Python 2 code. To use, run
pip install black. To prettify your code, run:
black path/to/dir or
Check your test coverage
You're writing tests, right? Then you will want to make sure new code committed to your codebase is tested and doesn't drop your overall amount of test coverage. While percentage of test coverage is not the only metric you should use to measure the effectiveness and sufficiency of your tests, it is one way to ensure basic testing standards are being followed in your project. For measuring test coverage, we have one recommendation: Coverage.
Coverage has several options for the way it reports your test coverage to you, including outputting results to the console or to an HTML page and indicating which line numbers are missing test coverage. You can set up a configuration file to customize what Coverage checks for and make it easier to run.
To install, run
pip install coverage. To run a program and see its output, run
coverage run [path/to/module.py] [args], and you will see your program's output. To see a report of which lines of code are missing coverage, run
coverage report -m.
Continuous integration tools
Continuous integration (CI) is a series of processes you can run to automatically check for linter errors and test coverage minimums before you merge and deploy code. There are lots of free or paid tools to automate this process, and a thorough walkthrough is beyond the scope of this article. But because setting up a CI process is an important step in removing blocks to more readable and maintainable code, you should investigate continuous integration tools in general; check out Travis CI and Jenkins in particular.
These are only a handful of the libraries available to check your Python code. If you have a favorite that's not on this list, please share it in the comments.