Kotlin em equipe: code style e convenções que todos discutem

Kotlin em equipe: como parar de discutir sobre formatação e começar a escrever código

Você já fez um code review onde metade dos comentários se resumia a "coloque um espaço", "tire o espaço" ou "por que você está usando CamelCase e não snake_case"? Se sim — bem-vindo ao clube. Em qualquer equipe, mais cedo ou mais tarde surge a questão: code style e convenções Kotlin. E se não houver um acordo prévio, cada um vai puxar sua "perfeita" disposição de chaves.

Este artigo não é uma lista seca de regras. É um guia prático para tornar o código em Kotlin legível, uniforme e conveniente para toda a equipe. Vamos abordar as principais convenções, ferramentas de automação e dicas que economizarão horas de discussão em reuniões.

Por que code style em Kotlin não é sobre estética, mas sobre dinheiro

Vamos ser honestos: para o negócio, não importa se você coloca a chave na mesma linha ou na linha seguinte. Mas importa quanto tempo leva para integrar um novo desenvolvedor ao projeto. Pesquisas mostram que desenvolvedores gastam até 40% do tempo lendo código. Se o código for escrito em um code style Kotlin unificado, esse processo acelera significativamente.

Quando um projeto usa um estilo de código Kotlin unificado:

\n
• Novos membros da equipe entendem a estrutura do projeto mais rapidamente.
\n
• O code review é mais rápido — os revisores procuram erros de lógica, não espaços.
\n
• Reduz o número de bugs devido à formatação incorreta (sim, isso acontece).
\n
• Os diffs do Git ficam mais limpos — menos ruído de reformatação.
\n

Portanto, as convenções Kotlin não são um capricho do líder, mas uma ferramenta para aumentar a eficiência. E agora vamos ver como implementá-las sem dor.

Guia oficial: Kotlin Coding Conventions

Vamos começar pelo básico: a JetBrains tem um documento oficial — Kotlin coding conventions. Não é uma lei, mas pessoas sábias recomendam usá-lo como ponto de partida. Vamos percorrer os pontos-chave que mais frequentemente geram discussões.

Nomenclatura: CamelCase para sempre

Kotlin usa CamelCase para tudo: classes — com letra maiúscula (MyAwesomeClass), funções e variáveis — com letra minúscula (myAwesomeFunction). Constantes de nível superior ou dentro de objeto — SCREAMING_SNAKE_CASE. Nada de sublinhados em nomes de variáveis — isso não é Python.

// Correto\nclass UserProfile\nval userName: String\nfun getUserData(): UserData\n\n// Incorreto\nclass user_profile\nval user_name: String\nfun get_user_data(): UserData

Chaves: abrir na mesma linha

Kotlin segue a tradição do Java: a chave de abertura — na mesma linha da declaração. Isso não é negociável, a menos que você queira ser visto como herege.

// Jeito Kotlin\nfun processData(data: List<String>) {\n    data.forEach { item ->\n        println(item)\n    }\n}\n\n// Jeito não-Kotlin (mas se toda a equipe escreve assim — ok)\nfun processData(data: List<String>)\n{\n    data.forEach { item ->\n        println(item)\n    }\n}

Espaços: não economize neles

Coloque espaços após palavras-chave (if, for, when), ao redor de operadores binários e após vírgulas. Isso melhora a legibilidade.

// Legível\nif (x > 0 && y < 10) {\n    println("Hello, World!")\n}\n\n// Difícil para os olhos\nif(x>0&&y<10){\n    println("Hello, World!")\n}

Autoformatação: seu melhor amigo

Verificação manual de code style é coisa do passado. Kotlin tem um formatador embutido no IntelliJ IDEA: Ctrl+Alt+L (ou Cmd+Option+L no Mac). Mas se na sua equipe alguém usa VS Code ou outro editor — os problemas são inevitáveis.

Solução: ktlint e Spotless.

ktlint: o soldado universal

ktlint é uma ferramenta que verifica e automaticamente