Как перестать спорить на ревью и доверить чистоту Kotlin-кода роботу

Представьте ситуацию: вы открываете очередной Pull Request, а там триста строк кода в одном методе, переменные названы буквами алфавита, а логика вложена друг в друга глубже, чем сны в фильме «Начало». Можно потратить час на вежливые комментарии, а можно делегировать эту грязную работу инструменту, который не устает и не ошибается.

Речь пойдет о detekt — статическом анализаторе для Kotlin. Если в мире Java все привыкли к Checkstyle или PMD, то для Kotlin-разработчиков именно этот проект стал стандартом де-факто, когда нужно быстро понять, насколько качественный код мы пишем.

detekt in action

Что это такое и зачем оно в вашем проекте

По сути, это линтер «на стероидах». Он не просто проверяет, стоят ли у вас лишние пробелы (хотя и это тоже), а ищет так называемые «запахи кода» (code smells). Это те самые места, которые технически работают, но в будущем гарантированно превратятся в головную боль для поддержки.

Проект живет долго, у него почти семь тысяч звезд на GitHub и огромное комьюнити. Это важно, потому что правила анализа постоянно обновляются под новые версии Kotlin, а количество плагинов позволяет настроить проверку под любые капризы команды.

Что умеет detekt на практике

Настройка инструмента гибкая, но я выделю несколько вещей, которые экономят больше всего времени.

Поиск логических аномалий

Инструмент подсвечивает слишком сложные условия, пустые блоки catch или огромные списки параметров в конструкторах. Например, если цикломатическая сложность метода зашкаливает, анализатор просто не даст собрать проект, пока вы не разобьете логику на части.

Использование Baseline для легаси

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

В detekt можно создать «baseline» — файл, который зафиксирует текущее состояние кода как «допустимое зло». Все старые ошибки будут игнорироваться, но любой новый код обязан быть чистым. Это позволяет внедрять инструмент в большие проекты без остановки разработки на месяц.

Гибкое подавление проверок

Иногда линтер ошибается или правило в конкретном месте мешает. В таких случаях не нужно лезть в конфиги — достаточно стандартной аннотации @Suppress("RuleName") прямо в коде. Это прозрачно и сразу видно на ревью.

Отчеты на любой вкус

Он умеет генерировать отчеты в HTML, Markdown и XML. Если вы используете GitHub Actions, формат SARIF позволит видеть замечания прямо в интерфейсе проверки пулл-реквестов.

Как быстро завести это у себя

Самый простой способ для тех, кто сидит на Gradle — подключить плагин. Выглядит это примерно так:

plugins {
    id("io.gitlab.arturbosch.detekt") version "1.23.8"
}

detekt {
    // Использовать стандартные настройки как базу
    buildUponDefaultConfig = true 
    // Путь к вашему конфигу
    config.setFrom("$projectDir/config/detekt.yml") 
    // Тот самый файл для легаси-кода
    baseline = file("$projectDir/config/baseline.xml") 
}

Кстати, если вам не хватает стандартных правил, detekt отлично дружит с ktlint. Можно подключить обертку, и тогда один инструмент будет проверять и форматирование, и сложную логику.

dependencies {
    detektPlugins("io.gitlab.arturbosch.detekt:detekt-rules-ktlint-wrapper:1.23.8")
}

Техническая сторона вопроса

Инструмент работает на основе абстрактного синтаксического дерева (AST), которое предоставляет компилятор Kotlin. Это позволяет ему понимать контекст кода гораздо лучше, чем обычным регулярным выражениям.

Для работы требуется Java 17+ (для сборки самого инструмента), но проверять он может код, ориентированный на Java 1.8 и выше. В последних версиях разработчики активно готовятся к переходу на K2 — новый компилятор Kotlin, так что проект точно не заброшен.

Кому стоит попробовать

Я бы советовал ставить detekt сразу, как только над проектом начинает работать больше одного человека.

Для команд: чтобы не тратить время на споры о стиле кода и сложности функций. Правила прописаны в конфиге, и спорить с роботом бесполезно.
Для соло-разработчиков: это отличный способ держать себя в тонусе и не лениться писать аккуратно.
Для тех, кто учит Kotlin: линтер часто подсказывает более идиоматичные способы решения задач.

Единственный минус — первичная настройка конфига под себя может занять пару часов, так как правил очень много. Но эти часы окупаются уже через неделю активного кодинга.

Если вы еще не используете статический анализ, попробуйте начать с дефолтных настроек. Скорее всего, вы удивитесь, сколько интересного detekt найдет в вашем «идеальном» коде.