Статический анализ кода для Kotlin

Начиная писать этот пост, я решил посмотреть, а писал ли я про статический анализ кода? Оказалось что ни одного развёрнутого поста про это у меня нет. Видимо я подразумеваю что это неотъемлемая часть разработки. Однакого мой опыт подсказывает, что то, что является “очевидным” и “неотъемлемым” для меня, наверняка будет чем-то новым для кого-то. Это вдвойне забавно, потому что я много выступал на эту тему (например, на Яндекс.Субботнике). В общем обещаю в ближайшее время посвятить отдельный пост статическому анализу, а пока - практическое руководство по его настройке для связки maven + kotlin. Тут же подумал, что котлин тоже достоин отдельной статьи (или даже серии статей), но обо всём по порядку.

Добавляем плагин

Инструмент, который я выбрал для статического анализа называется detekt. Автор почему-то решил, что maven-плагин ему не нужен, однако есть “неофициальная” версия - detekt-maven-plugin, на которую сам автор и ссылается в документации. Добавь плагин в секцию build -> plugins:

    <plugin>
        <groupId>com.github.ozsie</groupId>
        <artifactId>detekt-maven-plugin</artifactId>
        <version>${detekt.version}</version>
        <executions>
            <execution>
                <phase>verify</phase>
                <goals>
                    <goal>check</goal>
                </goals>
            </execution>
        </executions>
        <configuration>
            <config>${project.basedir}/detekt-config.yml</config>
        </configuration>
        <dependencies>
            <dependency>
                <groupId>io.gitlab.arturbosch.detekt</groupId>
                <artifactId>detekt-formatting</artifactId>
                <version>${detekt.version}</version>
            </dependency>
        </dependencies>
    </plugin>

Обрати внимание на модуль detekt-formatting в зависимостях плагина. Без него не будут работать проверки, связанные с “code style”. Я был весьма удивлён, когда это обнаружил - detekt просто игнорирует правила без этой зависимости. Сам модуль - обёртка над другим инструментом - ktlint.

В секции executions мы говорим плагину чтобы проверка выполнялась во время вызова maven-команды verify (можно заменить на test или что ты там вызываешь в своих билдах).

В configuration - путь к файлу с найстройками плагина.

Настраиваем плагин

Чтобы сгенерировать файл конфигурации с настройками по-умолчанию, достаточно выполнить mvn detekt:generate-config. Полученный файл default-detekt-config.yml положи по пути, который указал в конфигурации.

В дефолтном конфиге почему-то часть правил отключена для тестов (секция test-pattern). Я рекомендую не делать этого и относиться к коду тестов так же строго, как и к продакшн коду.

Ещё один интересный момент - большинство правил в секции formatting имеют опцию autoCorrect: true - плагин автоматически исправит эти проблемы. Спасибо разработчикам ktlint, которые “принесли” эту фичу из инструментов экосистемы JavaScript и Go =).

У плагина есть встроенный настраиваемый порог допустимых ошибок, поэтому можно обойтись без внешних тулов вроде Sonar’a.