Code Review em Kotlin: 7 Armadilhas Que Arruínam Seu Projeto

Por que o code review em Kotlin não é sobre "eu escreveria diferente"?

O code review (ou revisão de código) é um ritual sagrado em qualquer equipe que se preze. Mas quando o assunto é Kotlin, muitos desenvolvedores ficam perdidos. "Tudo aqui é tão conciso!", "Bom, é uma linguagem baseada em expressões" — você pensa, enquanto folheia o pull request. E é aí que mora o perigo.

Kotlin é bonito, mas traiçoeiro. Ele oferece ferramentas poderosas: scope functions, sealed classes, corrotinas. E a mesma quantidade de maneiras de dar um tiro no pé. Neste artigo, vamos analisar o que realmente importa em um code review de Kotlin, para que seu código não se transforme em um "monstro de espaguete" com efeitos colaterais anuláveis.

Este artigo não é um tutorial de sintaxe. É um checklist prático para o revisor que quer ver não apenas código funcional, mas um produto sustentável e seguro.

1. Null Safety: quando "?" não é uma panaceia

Kotlin se orgulha de sua Null Safety. E com razão. Mas no code review, você deve verificar não apenas a presença de "!!", mas a lógica de trabalhar com tipos anuláveis.

O que deve acender o alerta?

\n
• Uso descontrolado de "!!". Se o desenvolvedor usa !!, ele deve explicar em um comentário por que esse valor é garantidamente não nulo. Se não houver explicação, é um bug.
\n
• Cadeias de safe call (?.) e elvis (?:). Elas frequentemente mascaram erros lógicos. Exemplo:
\n

// Problema: se user?.address?.city == null,\n// retornamos "Unknown" silenciosamente, sem log\nval city = user?.address?.city ?: "Unknown"\n

Como deveria ser? Se null é uma situação excepcional, use requireNotNull ou checkNotNull. Se for um comportamento normal, registre no log.

val city = user?.address?.city\n    ?: run {\n        logger.warn("Usuário $userId não tem cidade")\n        "Unknown"\n    }\n

Em um code review de Kotlin, sempre pergunte: "E se esse null for um bug que estamos silenciando agora?"

2. Scope Functions: let, apply, run — use com sabedoria

As scope functions são o poder do Kotlin. Mas na prática, vejo elas sendo usadas como um martelo para qualquer prego. A revisão de código Kotlin deve incluir a análise: "Por que let aqui e não run?"

Armadilhas comuns:

\n
• let para verificação de null. Ok, mas não os aninhe uns nos outros:
\n

// Péssimo\nuser?.let { u ->\n    address?.let { a ->\n        process(u, a)\n    }\n}\n\n// Bom\nif (user != null && address != null) {\n    process(user, address)\n}\n

\n
• apply para mutação de objetos. Essa é a sua praia. Mas se você usa apply dentro de let — pare. Isso cheira a espaguete.
\n

Lembre-se: with é para agrupar chamadas, also para efeitos colaterais (logging), run para cálculos em contexto. Não os confunda.

3. Imutabilidade: var é um pano vermelho

Kotlin promove o uso de val. E isso é ótimo. Mas na revisão de código Kotlin, vejo frequentemente desenvolvedores usando var onde val com cópia seria suficiente.

// Ruim\nvar result = mutableListOf<Int>()\nitems.forEach { result.add(it * 2) }\n\n// Bom\nval result = items.map { it * 2 }\n

A regra é simples: se você vir var, pergunte: "Por que não val?" Na maioria das vezes, a resposta vai te surpreender: "Não pensei nisso."

A exceção é apenas quando a mutação é realmente necessária (por exemplo, em loops com acumulação). Mas mesmo assim, muitas vezes pode ser substituído por fold ou reduce.

4. Sealed Classes e when: não se esqueça do else

Sealed classes são uma alternativa elegante