Revisão de código em Kotlin: o que irrita os desenvolvedores seniores

Como os seniores veem seu código Kotlin: análise com exemplos reais

Você escreveu o código, enviou para o repositório e espera ansiosamente pela aprovação. Mas, em vez do sinal verde, chegam dezenas de comentários do desenvolvedor sênior. Familiar? Se você programa em Kotlin, certamente já passou pela situação em que seu código, aparentemente perfeito, após o code review se transforma em abóbora.

Neste artigo, vamos analisar quais comentários típicos de seniores são mais comuns durante a revisão de código em Kotlin. Não vamos ensinar sintaxe — vamos mostrar como escrever para que seu código passe na revisão de primeira. Vamos lá!

1. Null Safety: "Por que você não usa o operador elvis?"

Um dos principais recursos do Kotlin é a null safety. Mas muitos desenvolvedores, especialmente os vindos do Java, continuam escrevendo código no estilo "verifique-se-é-null-e-execute". Os seniores percebem isso imediatamente.

Exemplo ruim (estilo Java)

fun getUserName(user: User?): String {\n    return if (user != null) {\n        user.name\n    } else {\n        "Unknown"\n    }\n}

Exemplo bom (estilo Kotlin)

fun getUserName(user: User?): String {\n    return user?.name ?: "Unknown"\n}

O uso do operador elvis (?:) e da safe call (?.) torna o código conciso e legível. Os seniores adoram quando você economiza linhas sem perder clareza. Lembre-se: if (x != null) { ... } else { ... } é um mau hábito.

2. Extension Functions: "Onde estão suas utilitárias?"

Quando você vê uma classe utilitária estática no estilo StringUtils.capitalize(str), um desenvolvedor experiente em Kotlin vai torcer o nariz. As extension functions são o que torna o Kotlin tão elegante.

Exemplo ruim

object StringUtils {\n    fun capitalize(text: String): String {\n        return text.replaceFirstChar { it.uppercase() }\n    }\n}\n\n// Uso\nval result = StringUtils.capitalize("hello")

Exemplo bom

fun String.capitalizeFirst(): String {\n    return this.replaceFirstChar { it.uppercase() }\n}\n\n// Uso\nval result = "hello".capitalizeFirst()

Os seniores dirão: "Por que você está criando um objeto lixeira? Apenas estenda a classe!" Use extension functions — isso melhora a legibilidade e segue o princípio das Kotlin best practices.

3. Sealed Classes em vez de Enum: "Seu enum está obsoleto"

Enums em Kotlin são bons, mas as sealed classes oferecem muito mais flexibilidade. Especialmente quando você precisa armazenar diferentes tipos de dados em uma mesma hierarquia.

Exemplo ruim (enum)

enum class Result {\n    SUCCESS,\n    ERROR,\n    LOADING\n}\n\nfun handleResult(result: Result) {\n    when (result) {\n        Result.SUCCESS -> // ...\n        Result.ERROR -> // ...\n        Result.LOADING -> // ...\n    }\n}

Exemplo bom (sealed class)

sealed class Result {\n    data class Success(val data: List<Item>) : Result()\n    data class Error(val message: String, val code: Int) : Result()\n    object Loading : Result()\n}\n\nfun handleResult(result: Result) {\n    when (result) {\n        is Result.Success -> println("Data: ${result.data}")\n        is Result.Error -> println("Error: ${result.message}")\n        Result.Loading -> println("Loading...")\n    }\n}

Os desenvolvedores seniores apreciarão que você use sealed classes para representar estados. Esta é uma das principais dicas senior kotlin — torne as hierarquias de tipos explícitas.

4. Scope Functions: "Você esqueceu do let, apply e run"

As scope functions (let, apply, run, with, also) são poderosas