Какие инструменты используются для проверки качества кода в Python?

Что проверяют

Есть ли у вас привычка к автоматическим проверкам и знаете ли вы современный набор, а не список пятилетней давности. Главное: понимаете ли вы, что ловит каждая проверка и где она запускается. Следом часто просят показать конфиг в pyproject.toml или рассказать, как вы внедряли линтер в старый проект.

Как отвечать

Разложите по типам проверок:

• линтер: Ruff, который заменяет Flake8, isort, pyupgrade и заметную часть правил Pylint и работает в разы быстрее. По умолчанию включены только наборы E4, E7, E9 и F, остальное подключается через select, например I, B, UP, S;
• форматтер: Black или ruff format, совместимый с ним по стилю. Спор о стиле закрывается раз и навсегда;
• типы: mypy или pyright. Новый код лучше проверять в режиме strict, в легаси вводить постепенно по модулям через [[tool.mypy.overrides]];
• тесты: pytest с фикстурами и параметризацией, покрытие через pytest-cov на базе coverage.py;
• безопасность: bandit или правила S в Ruff для кода, pip-audit для уязвимостей в зависимостях;
• запуск: хуки pre-commit локально и те же проверки в CI на каждый merge request, чтобы красная сборка блокировала слияние.

Хорошо добавить, как вы внедряли это в существующий проект: сначала форматтер одним коммитом, затем линтер с базовым набором, новые правила по одному, чтобы не получить тысячу замечаний разом. Если в команде проверок не было, так и скажите и объясните, какой минимальный набор поставили бы первым.

Где спотыкаются

Говорят, что Black «форматирует по PEP 8». У Black свой стиль, в целом совместимый с PEP 8, но не тождественный ему, и в связке с Flake8 приходится отключать конфликтующие проверки вроде E203.

Относят профилировщики к проверке качества. cProfile и line_profiler отвечают на вопрос «где медленно», а не «где ошибка», и гейтом в CI не работают.

Засыпают код # type: ignore и # noqa без кода правила. Подавлять стоит конкретную ошибку, например # type: ignore[arg-type], иначе вместе с ней спрячется и следующая.