Robust Python

Chapter 20. Static Analysis

Before I get to testing, I first want to talk about static analysis. Static analysis is a set of tools that inspect your codebase, looking for potential errors or inconsistencies. It’s a great asset for finding common mistakes. In fact, you’ve already been working with a static analysis tool: mypy. Mypy (and other typecheckers) inspect your codebase and find typing errors. Other static analysis tools check for other types of errors. In this chapter, I’ll walk you through common static analyzers for linting, complexity checking, and security scanning.

Linting

The first class of static analysis tools that I’ll walk you through is called a linter. Linters search for common programming mistakes and style violations within your codebase. They get their name from the original linter: a program named lint that used to check C programs for common errors. It would search for “fuzzy” logic and try to remove that fuzz (hence, linting). In Python, the most common linter you will come across is Pylint. Pylint is used to check for a myriad of common mistakes:

• Certain style violations of the PEP 8 Python style guide

• Dead code that is unreachable (such as code after a return statement)

• Violations of access constraints (such as private or protected members of a class)

• Unused variables and functions

• Lack of cohesion in a class (no use of self in a method, too many public methods)

• Missing documentation in the form of docstrings

• Common programming errors ...