Использование code-style плагина ktlint в Kotlin проекте. Краткая инструкция для backend-разработчика

Моя цель - предложение широкого ассортимента товаров и услуг на постоянно высоком качестве обслуживания по самым выгодным ценам.

Я работаю Java/Kotlin-разработчиком в компании EPAM.

В первой статье я рассказывала про свой проект — Brain-Up

В этой статье хочу поделиться опытом настройки плагина ktlint для Kotlin проекта.

Данный плагин помогает обеспечивать единый code style на проекте. Он построен на официальных рекомендациях по форматированию кода для Kotlin от JetBrains. С помощью данного инструмента можно не только проверить код, но и отформатировать его.

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

Потому решила поделиться свои опытом, надеюсь кому-то будет полезна пошаговая инструкция подключения к проекту. Этот пример актуален для проекта на Kotlin 1.4, gradle 6.0. 

#1. Добавление зависимости в build.gradle на плагин

dependencies {    
    ktlint "com.pinterest:ktlint:0.38.0"
}

#2. Добавление gradle таски `ktlintFormat`

С её помощью можно отформатировать весь проект сразу, т.е. большая часть рекомендаций будет применена автоматически, останется только добавить/удалить пустые строчки вручную при необходимости или что-то такое, что не удалось исправить этой таске. 

task ktlintFormat(type: JavaExec, group: "formatting") 
{
    description = "Fix Kotlin code style deviations."    
    classpath = configurations.ktlint    
    main = "com.pinterest.ktlint.Main"    
    args "-F", "src/*/.kt"
}

#3. Конфигурирование gradle таски `ktlint` для вашего проекта

project.task("ktlint", type: JavaExec) {    
    group = "verification"    
    description = "Runs ktlint."    
    main = "com.pinterest.ktlint.Main"    
    classpath = project.configurations.ktlint    
    args = [            
        "--reporter=plain",            
        "--reporter=checkstyle,output=${project.buildDir}/reports/ktlint/ktlint-checkstyle-report.xml",            
        "src/*/.kt"    ]
}

#4. Встраивание таски `ktlint` в процесс сборки приложения

compileKotlin.dependsOn ktlint

В данном случае проверка форматирования кода будет запускаться до компиляции. Чем быстрее мы узнаем о несоответствии, то есть упадет эта проверка, тем лучше. В этом случае можно всё быстро исправить. 

Если возникает ошибка форматирования, то мы увидим примерно такое сообщение, из которого понятно, что и где не так. 

Правим форматирование.

#5. Настройка параметров Idea для правильного форматирования

Это можно настроить здесь File -> Settings -> Code Style -> Kotlin.

#6. Форматирование текущего класса

Первый способ.

Мне удобно при работе с классом сразу по окончании нажать Ctrl+Alt+L, и класс автоматически отформатируется согласно установленным в Idea свойствам форматирования. Если выделить мышкой папочку в проекте и нажать на ней данную комбинацию, то отформатируются все классы в этой папочке согласно настройкам Idea, которые мы задали выше. 

Второй способ.

Если не хочется настраивать Idea и пользоваться её возможностями форматирования ― можно перед сборкой запустить таску ktlintFormat — она отработает для всего проекта.

#7. Выключение правил

Если что-то не очень нравится и сильно хочется выключить правило, которое мешает, это можно сделать с помощью добавления специального файла .editorconfig и там выключать правила. 

Например, мы в проекте отказались от правила необходимости импортов быть отсортированными в лексикографическом порядке. То есть правило может это и не плохое, оно, кстати, недавно в плагине появилось, только вот  Ctrl+Alt+L  импорты не группирует и таска их  ktlintFormat  тоже, а делать это каждый раз руками надоедает. 

[*.{kt,kts}]
disabled_rules = import-ordering

Резюме

Так выглядит в build.gradle добавление плагина в итоге у нас на проекте. Работаем с ним 2-й год, всё стабильно пока. 

Если у вас есть свои идеи, опыт, как улучшить / решить задачу единого code style на Kotlin проекте, — пишите в комментариях, будет интересно узнать: какими вы пользуетесь плагинами, насколько они удобны, стабильны к обновлениям языка и быстро настраиваемы. 

Полный пример, при желании, можно посмотреть в нашем открытом репозитории Open Source социального проекта Brain-up, к которому может присоединиться любой желающий, получить опыт работы в профессиональной команде и принести реальную пользу обществу. 

В следующей статье постараюсь рассказать про подключение Sonar Cloud к Kotlin проекту, по которому тоже было немало вопросов, когда у себя его настраивали.  

Всем удачи! 

Источник: https://habr.com/ru/company/epam_systems/blog/545040/


Интересные статьи

Интересные статьи

Привет, Хабр! Продолжая исследование темы C#, мы перевели для вас следующую небольшую статью, касающуюся оригинального использования extension methods. Рекомендуем обратить особое ...
В обновлении «Сидней» Битрикс выпустил новый продукт в составе Битрикс24: магазины. Теперь в любом портале можно создать не только лендинг или многостраничный сайт, но даже интернет-магазин. С корзино...
Машинное обучение плотно укоренилось в различных сферах деятельности людей: от распознавания речи до медицинской диагностики. Популярность этого подхода столь велика, что его пытаются использов...
Те, кто собираются открывать интернет-магазин, предварительно начитавшись в интернете о важности уникального контента, о фильтрах, накладываемых поисковиками за копирование материалов с других ресурсо...
Мы публикуем видео с прошедшего мероприятия. Приятного просмотра.