Hypermodern Python Tooling

Chapter 9. Linting with Ruff and pre-commit

In 1978, Stephen C. Johnson, a researcher at Bell Labs, wrote a program that could detect a number of bugs and obscurities in C code. He named the program after the fluff on your pullover when you take it out of the washing machine: Lint. It was to become the first in a long line of linters, programs that analyze source code and point out problematic constructs.

Linters don’t run a program to discover issues with it; they read and analyze its source code. This process is known as static analysis, as opposed to runtime (or dynamic) analysis. It makes linters both fast and safe—​you needn’t worry about side effects, such as requests to production systems. Static checks can be smart and also fairly complete—​you needn’t hit the right combination of edge cases to dig up a latent bug.

Note

Static analysis is powerful, but you should still write tests for your programs. Where static checks use deduction, tests use observation. Linters verify a limited set of generic code properties, while tests can validate that a program satisfies its requirements.

Linters are also great at enforcing a readable and consistent style, with a preference for idiomatic and modern constructs over obscure and deprecated syntax. Organizations have adopted style guides for years, such as the recommendations in PEP 8 or the Google Style Guide for Python. Linters can function as executable style guides: by flagging offending constructs automatically, they keep code ...