Что такое линтер — робот, который находит баги, не запуская код

Смотри, какая штука: самый частый баг новичка — это не хитрая логическая ошибка. Это опечатка. Написал usename вместо username, и приложение падает где-то через десять минут, в совсем другом месте. Ты полчаса ищешь сложную причину — а её нет.

Линтер находит такую опечатку за миллисекунды. Не запуская код вообще. Он просто читает его — как очень внимательный, слегка занудный друг.

Линтер читает код как текст

Линтер (linter) — программа, которая анализирует твой код, не выполняя его. Она смотрит на текст программы и ищет два типа проблем:

• Вероятные баги. Переменная объявлена, но нигде не используется. Функция вызвана с опечаткой в имени. Код после return, до которого никогда не дойдёт выполнение. Сравнение = там, где явно имелось в виду ==.
• Неопрятность. Разнобой кавычек, лишние отступы, слишком длинные строки. Это не баги, но в неопрятном коде баги прячутся лучше.

Ключевое отличие от запуска: запуск проверяет один сценарий («я нажал кнопку — сработало?»), а линтер проверяет весь текст сразу, включая ветки, до которых ты при проверке руками не дошёл бы.

Название, кстати, от слова lint — «катышки на одежде». Линтер снимает катышки с кода.

Как это выглядит на практике

Ты почти наверняка уже видел линтер в работе, просто не знал, как он называется. Красное или жёлтое подчёркивание в редакторе кода — это он. Наведёшь курсор — линтер объяснит претензию:

'username' is assigned a value but never used  (no-unused-vars)

Читается любое такое сообщение по одной схеме: где (файл и строка) → что не так (описание) → имя правила в скобках. Имя правила — самое полезное: его можно спросить у ИИ («что значит no-unused-vars и как починить») или погуглить, и получишь точный ответ, а не догадки.

У каждого языка свой стандартный линтер: в JavaScript и TypeScript это ESLint, в Python — Ruff (раньше — Flake8/Pylint), в Swift — SwiftLint. Если ты вайб-кодишь в Cursor или другом ИИ-редакторе — линтер там, скорее всего, уже включён из коробки.

Зачем линтер, если код пишет ИИ

Кажется, что с ИИ линтер не нужен: модель же пишет аккуратно. На деле наоборот — линтер стал нужнее.

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

Отсюда практичный приём: получил от ИИ кусок кода — глянь на подчёркивания линтера раньше, чем запускать. Жёлтая волна на «неиспользуемой переменной» — верный признак, что модель что-то недоделала, и стоит спросить её: «переменная X объявлена, но не используется — так задумано?»

Линтер, форматтер, тесты — кто за что отвечает

Рядом с линтером живут два соседа, и их легко перепутать:

• Форматтер (Prettier, swiftformat) — только внешний вид: отступы, кавычки, переносы. Ничего не ищет, просто причёсывает.
• Линтер — подозрительные места и вероятные баги. Читает, но не запускает.
• Тесты — реальное поведение: запускают код и сверяют результат с ожидаемым.

Это три уровня защиты, и они не заменяют друг друга. В серьёзных проектах все три гоняются автоматически на каждое изменение — это часть CI/CD, и красный «крестик» на коммите часто означает именно «линтер нашёл проблему», а не «всё сломалось».

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

Линтер исправляет ошибки сам?

Часть — да. У большинства линтеров есть режим автопочинки (eslint --fix): он сам убирает лишнее и правит мелочи, где исправление однозначно. Но логические баги он не чинит — только показывает.

Линтер ругается на рабочий код — он сломан?

Нет, так и задумано. Линтер ищет подозрительное, а не гарантированно сломанное — иногда подозрение ложное. Правила можно настраивать, а в крайнем случае — точечно отключить для одной строки специальным комментарием. Но сначала честно прочитай претензию: чаще всего линтер прав.

Нужно ли ставить линтер самому?

Если пишешь в Cursor, VS Code или другом современном редакторе — скорее всего, он уже работает: смотри на подчёркивания. Отдельно ставить имеет смысл, когда проект растёт: одна команда (pnpm add -D eslint и pnpm eslint .) — и проверка гоняется на весь проект целиком, а не только на открытый файл.