Современная разработка программного обеспечения требует не только написания функционального кода, но и обеспечения его качества, надежности и безопасности.
Для обеспечения этого во многих командах по-прежнему существует Code Review. По моему мнению в 90% случаев это абсолютно бесполезная трата времени и сил разработчиков команды. Code Review это рудимент, который изжил себя. Я не утверждаю, что Code Review должен исчезнуть - принцип и подход должны измениться.
Ручная организация Code Review ведет к деградации продуктивности и взаимоотношений внутри команды. Очень часто Code Review превращается в способ самоутверждения, эмоциональной разрядке одного из участников команды за счет других. Комментарии часто бывают противоречивыми и контр продуктивными.
Как этого избежать?
Ответ – полностью автоматизировать этот процесс.

Одним из ключевых инструментов для достижения этой цели является статистический анализ кода - метод автоматизированной проверки исходного кода без его выполнения.

Я всю свою практику участвовал в командах, где Code Review было ручным и каждый участник команды ставил approve, либо оставлял комментарий. Думаю, так происходит и сейчас во многих командах. Качество такого Review низкое и трудно быть по-настоящему объективным.

Мне повезло участвовать в большом стартапе и начать проект самостоятельно. И в моем проекте я решил покончить с Code Review в привычном понимании.

Что мне было необходимо? Нужен был инструмент, который бы приводил код к единому стилю и избавил меня и других участников команды от необходимости проверять стиль кода. Сюда входит правила расстановки новых строк, именования методов, отступы и тд. Необходимо чтоб инструмент подсвечивал места где стиль не соблюдается и исправлял автоматически такие места.

В данной статье я рассмотрю только анализ стиля Kotlin кода и его автоматическое исправления согласно выработанным правилам в проекте.
Использовать будем Kotlinter.

Как подключить плагин:

plugins {
    id 'org.jmailen.kotlinter' version "5.0.2" apply false
}

plugins {
    //for groovy
    id 'org.jmailen.kotlinter'
    //for kts
    id("org.jmailen.kotlinter")
} 

Далее создаем .editorconfig файл на самом верхнем уровне проекта (там где лежит файл settings.gradle) в котором будем описывать правила стиля кода.
Всю документацию по написанию правил стиля можно прочитать тут (Pinterest).

root = true

[*.{kt,kts}]
ktlint_code_style = android_studio

indent_size = 4
indent_style = space
max_line_length = 120

// для проверки кода и вывода мест которые нарушают стилистику кода
./gradlew lintKotlin
// для автоматичекого исправления кода
./gradlew formatKotlin

Такой вариант уже будет автоматически сортировать импорты, удалять неиспользуемые импорты, удалять пустые строки.

Детальная настройка

Не буду пересказывать документацию. Там все детально и с примерами описано.
Приведу лишь полный мой файл который существует сейчас в нашей команде:

root = true

[*.{kt,kts}]
ktlint_code_style = android_studio

indent_size = 4
indent_style = space
max_line_length = 120

ktlint_function_naming_ignore_when_annotated_with = Composable

ktlint_experimental = enabled

ktlint_chain_wrapping = disabled
ktlint_import_ordering = enabled
ktlint_trailing_comma_on_call_site = false
ktlint_trailing_comma_on_declaration_site = false
ktlint_function_signature = enabled
ktlint_function_signature_body_expression_wrapping = always
ktlint_spacing_around_parens = enabled
ktlint_modifier_order = enabled
ktlint_no_wildcard_imports = enabled
ij_kotlin_line_break_after_multiline_when_entry = false
ktlint_class_signature_rule_force_multiline_when_parameter_count_greater_or_equal_than = 1
ktlint_function_signature_rule_force_multiline_when_parameter_count_greater_or_equal_than = 2
ktlint_standard_function-expression-body = disabled

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

Добавить автоформатирование при каждом Build можно создать task в gradle

tasks.getByPath("preBuild").dependsOn("formatKotlin")

Буду рад рад, если написав эту короткую статью я помогу сэкономить силы и время командам и сместить фокус на более важные моменты требующие человеческого внимания.