Linters & formatters
The tools that check and format Python code, described from their official documentation: pycodestyle and its error codes, flake8, pylint, black, ruff and pre-commit hooks.
- Black, the Python Code Formatter: How It Works and How to Configure It
What the Black formatter does and why it has so few options: the 88-character line, double quotes, the magic trailing comma, its stability policy, configuration in pyproject.toml, and making it work with flake8, isort and git blame.
- How to Check Python Code Style Locally with pycodestyle, flake8 and ruff
Step-by-step: install pycodestyle, flake8 or ruff in a virtual environment, run them on a file or a project, read the output, configure line length and rules in setup.cfg or pyproject.toml, fix issues automatically and run the checks in CI.
- Pre-commit Hooks for Python: Run Linters and Formatters Before Every Commit
How git pre-commit hooks work and how the pre-commit framework manages them: a .pre-commit-config.yaml for whitespace fixes, ruff and formatting, installing, running on all files, updating hook versions and using the same checks in CI.
- Ruff for Python: Linter and Formatter, Rule Selection and Configuration
What ruff is and how to use it: rule codes borrowed from pycodestyle, pyflakes and flake8 plugins, selecting rules in pyproject.toml, safe and unsafe fixes, the formatter, preview rules, and how it relates to flake8 and Black.
- flake8 and pylint: What Each Python Linter Checks and How They Differ
A neutral comparison of flake8 and pylint based on their documentation: what each one checks, how they report problems, configuration files, plugins and message control, with the output of both on the same file.
- pycodestyle Error Codes Explained: E1 to E9 and W1 to W6
A reference to pycodestyle's error and warning codes, family by family: what E101, E225, E302, E501, E711, W291 and the others mean, how to fix them, which are ignored by default, and how to select, ignore or silence codes.
