Какие проверки стоит автоматизировать с помощью линтеров и форматтеров, чтобы не тратить на них время на ревью?

Линтеры и форматтеры — это инструменты статического анализа, которые проверяют исходный код без его выполнения. Их главная задача — снять с команды рутинные проверки, которые не требуют человеческого суждения: отступы, кавычки, точки с запятой, порядок импортов, длину строк, именование переменных. Когда эти правила автоматизированы, ревьюер не тратит время на споры о стиле и может сосредоточиться на логике, архитектуре и потенциальных багах.

Что стоит автоматизировать

• Форматирование: отступы, переносы строк, кавычки, точки с запятой, максимальная длина строки.
• Стиль языка: порядок импортов, запрет неиспользуемых переменных и параметров, предпочтение const вместо let.
• Потенциальные ошибки: сравнение через == вместо ===, отсутствие await, необработанные промисы, доступ к неопределённым переменным.
• Безопасность: запрет eval, опасные регулярные выражения, устаревшие API.
• Соглашения проекта: именование файлов, структура папок, запрет console.log в продакшене.

Пример настройки в проекте

Обычно линтер и форматтер настраивают один раз и подключают к pre-commit хуку и CI. Например, для JavaScript это ESLint и Prettier:

// .eslintrc.json
{
  "extends": ["eslint:recommended", "plugin:react/recommended"],
  "rules": {
    "no-unused-vars": "error",
    "eqeqeq": "error",
    "no-console": "warn"
  }
}

// package.json
"scripts": {
  "lint": "eslint . --ext .js,.ts",
  "format": "prettier --write ."
}

// .husky/pre-commit
npm run lint && npm run format

Как это влияет на ревью

Когда стиль проверяется автоматически, ревью становится быстрее и объективнее. Ревьюер видит только содержательные замечания, а не придирки к пробелам. Кроме того, CI не пропустит код с ошибками линтера, поэтому в основную ветку попадает только согласованный код. Это снижает количество конфликтов в команде и ускоряет интеграцию изменений.

Итог: автоматизируйте всё, что можно проверить формально — стиль, форматирование, простые баги и нарушения соглашений. Это освобождает время на ревью логики и архитектуры, где действительно нужен человек.