Что такое линтеры и форматтеры и как с ними работать

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

Настраивали ли вы это сами или пользовались тем, что включили до вас. По ответу видно, как в команде устроено ревью: спорят там о пробелах и кавычках или о сути изменений.

Как отвечать

Разделите три класса инструментов, их постоянно путают.

Форматтер переписывает код по единому стилю и не обсуждается: black или ruff format. Смысл не в красоте, а в отсутствии споров и в чистых диффах, где видно только смысловое изменение.

Линтер ищет подозрительное: неиспользуемые импорты и переменные, затенение имён, изменяемое значение по умолчанию у аргумента, недостижимый код, нарушения стиля. Сегодня это обычно ruff, заменивший связку из flake8, isort и части плагинов и работающий заметно быстрее. pylint даёт более глубокие проверки, но медленнее и шумнее.

Проверка типов это отдельный класс, а не линтер: mypy или pyright читают аннотации и ловят то, чего линтер не видит в принципе.

Работа с ними выглядит так:

ruff format .
ruff check --fix .
mypy src

Настройки лежат в pyproject.toml, одним местом для всей команды. Локально запуск вешается на хуки pre-commit, в сборке те же команды идут в режиме проверки (ruff format --check, ruff check), и падение блокирует слияние.

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

Настраивают локально, а в сборке не проверяют. Тогда стиль держится на дисциплине и разъезжается на первом же срочном исправлении, а следующий дифф состоит из перемешанных правок формата и логики.

Глушат предупреждения голым # noqa без кода правила. Такой комментарий заодно прячет будущие ошибки в этой строке. Если правило команде не подходит, его выключают в конфиге и один раз, а не по месту и навсегда.

Прогоняют форматтер по старому проекту вместе с правкой логики, и git blame во всех файлах указывает на один коммит. Формат меняют отдельным коммитом без смысловых изменений и добавляют его в список игнорируемых при разборе авторства.