Статический анализ Kotlin-приложений #

Документация на статический анализ #

• Проверка и форматирование исходного кода с ktlint
• Плагин для системы сборки Gradle для запуска ktlint
• Статический анализатор кода detekt

Статический анализ исходного кода #

Статический анализ исходного кода применяется для решения следующих задач:

• Нахождение синтаксических и лексических проблем в исходном коде. Реализуется внутри компилятора языка.
• Обеспечение единого оформления для исходного кода.
• Предупреждение потенциальных проблем в исходном коде приложения.

Дополнительные материалы по анализу исходного кода:

• Использование статического и динамического анализа для повышения качества продукции и эффективности разработки, статья на сайте SWD Software.
• Внедряйте статический анализ в процесс, а не ищите с его помощью баги
• Статические анализаторы кода на примере ClickHouse

Проверка форматирования кода с помощью ktlint #

ktlint — инструмент для статического анализа форматирования исходного кода в соответствии с официальным соглашением о стилистике кода.

Для подключения к проекту необходимо:

• Добавить поддержку инструмента в систему сборки проекта Gradle.
• Добавить настройку стиля программирования в среду разработки OpenIDE.
• Использовать Gradle-задачи для проверки исходного кода на соответствие стилю.

Добавление поддержки в Gradle #

Инструмент ktlint может быть интегрирован разными способами, рассмотрим использование плагина Ktlint Gradle.

Необходимо добавить плагин в конфигурацию build.gradle.kts:

plugins{
    id("org.jlleitschuh.gradle.ktlint") version "14.2.0"
}

Внутри конфигурации необходимо указать версию инструмента. Для этого в файле gradle.properties укажите версию инструмента:

ktlintVersion=1.8.0

И в build.gradle.kts необходимо указать используемую версию инструмента:

val ktlintVersion: String by project

ktlint {
    version.set(ktlintVersion)
}

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

Настройка инструмента ktlint #

Ktlint поддерживает несколько стандартов оформления. Настройка производится путём формирования файла .editorconfig, который должен располагаться в корне проекта, рядом с файлами конфигурации системы сборки Gradle build.gradle.kts. Формат .editorconfig универсален: тот же файл читает форматтер OpenIDE, поэтому настройки редактора и анализатора совпадают.

В рамках курса необходимо использовать следующую конфигурацию для данного файла:

root = true

[*]
insert_final_newline = true

[{*.kt,*.kts}]
ktlint_code_style = ktlint_official
#  Настройки форматтера OpenIDE
ij_kotlin_code_style_defaults = KOTLIN_OFFICIAL
ij_kotlin_name_count_to_use_star_import = 2147483647
ij_kotlin_name_count_to_use_star_import_for_members = 2147483647
ij_kotlin_packages_to_use_import_on_demand = unset

Запуск проверки исходного кода #

После конфигурации можно запускать Gradle-задачу для проверки исходного кода ktlintCheck: ./gradlew clean ktlintCheck. Все сообщения о нарушениях форматирования необходимо исправить.

Ограничения и особенности:

• ktlint не работает корректно, если в полном пути к проекту есть символы, не относящиеся к латинскому алфавиту. Решение: размещать проект в каталоге, в полном пути к которому только латинские символы.
• Инструмент может выполнить кеширование результатов. Решение: перед выполнением команды ktlintCheck следует вызвать команду clean, которая очистит все артефакты сборки. Следует помнить, что после выполнения команды clean следующая сборка будет выполняться дольше.

Настройка форматирования в OpenIDE #

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

Анализ потенциальных проблем в исходном коде #

Инструмент detekt выполняет поиск потенциальных проблем в исходном коде. Примеры таких проблем:

• слишком длинные методы;
• большая вложенность циклов и условных операторов;
• неинформативные имена переменных;
• избыточные комментарии к исходному коду;
• «магические» числа и строковые литералы;
• неиспользуемый код.

Для использования инструмента необходимо:

• Сформировать правила проверки кода.
• Добавить конфигурацию для запуска инструмента в Gradle.
• Использовать Gradle-задачи для проверки исходного кода.

По желанию можно добавить расширение для OpenIDE.

Инструмент обязателен для использования в рамках курса. Все сообщения анализатора необходимо исправить.

Формирование набора правил проверки кода #

В настоящий момент используется базовая конфигурация инструмента без изменений и дополнений.

Важно: самостоятельно вносить изменения в конфигурацию инструмента запрещено. В частности запрещено подавлять сообщения от анализатора с помощью аннотаций (@Suppress) или baseline-файла — файла detekt-baseline.xml, в который записываются ранее найденные нарушения, чтобы исключить их из отчёта.

Добавление поддержки в Gradle #

Инструмент изначально предлагает расширение для Gradle. Для его использования необходимо добавить соответствующий плагин в build.gradle.kts:

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

Далее внутри конфигурации необходимо добавить настройку для проверки кода:

detekt {
    buildUponDefaultConfig = true
}

Запуск проверки исходного кода #

После конфигурации для проверки исходного кода можно запустить задачу detekt: ./gradlew detekt. Все сообщения от инструмента рекомендуется исправлять.

Настройка проверки внутри OpenIDE #

Проект detekt предоставляет возможность встроить проверку с помощью специального расширения.

Итоги #

Статический анализ выполняется двумя дополняющими инструментами. ktlint обеспечивает единое оформление исходного кода и запускается задачей ktlintCheck. detekt находит потенциальные проблемы: длинные методы, глубокую вложенность, плохие имена. Оба инструмента подключаются как плагины Gradle и запускаются командами ./gradlew clean ktlintCheck и ./gradlew detekt. Все сообщения анализаторов должны быть исправлены, а не подавлены.

Задача № 1. Добавление проверки оформления кода ktlint #

Добавьте проверку исходного кода с помощью инструмента ktlint в проект задания «Обработка HTTP-запросов с помощью http4k» (приложение для управления списком треугольников).

1. Подключите плагин Ktlint Gradle в build.gradle.kts.
2. Укажите версию инструмента в gradle.properties и build.gradle.kts.
3. Создайте файл .editorconfig с конфигурацией из раздела выше.
4. Настройте форматтер OpenIDE по официальному руководству.
5. Выполните команду ./gradlew clean ktlintCheck.
6. Исправьте все найденные нарушения форматирования.

Результат: команда ./gradlew clean ktlintCheck завершается с сообщением BUILD SUCCESSFUL.

Задача № 2. Анализ исходного кода с помощью detekt #

Добавьте в проект из задачи № 1 поддержку инструмента статического анализа detekt.

1. Подключите плагин io.gitlab.arturbosch.detekt в build.gradle.kts.
2. Добавьте блок конфигурации detekt с базовой конфигурацией.
3. Выполните команду ./gradlew detekt.
4. Исправьте все сообщения инструмента. Подавлять сообщения аннотациями и baseline-файлом запрещено.

Результат: команда ./gradlew detekt завершается с сообщением BUILD SUCCESSFUL.