Revue de code Kotlin : ce qui agace les développeurs seniors

Comment les seniors voient votre code Kotlin : analyse sur des exemples réels

Vous avez écrit du code, vous l'avez poussé dans le dépôt et vous attendez l'approbation avec impatience. Mais au lieu d'un feu vert, vous recevez une dizaine de commentaires d'un développeur senior. Ça vous parle ? Si vous codez en Kotlin, vous avez sûrement déjà vécu cette situation où votre code, pourtant parfait à vos yeux, se transforme en citrouille après un code review.

Dans cet article, nous allons décortiquer les remarques typiques des seniors les plus fréquentes lors d'une revue de code Kotlin. Pas question de vous apprendre la syntaxe — nous allons vous montrer comment écrire un code qui passe la review du premier coup. C'est parti !

1. Null Safety : « Pourquoi tu n'utilises pas l'opérateur Elvis ? »

L'un des atouts majeurs de Kotlin est la null safety. Mais beaucoup de développeurs, surtout ceux venant de Java, continuent d'écrire du code dans le style « vérifie-si-null-et-exécute ». Les seniors le repèrent immédiatement.

Mauvais exemple (style Java)

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

Bon exemple (style Kotlin)

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

L'utilisation de l'opérateur Elvis (?:) et de l'appel sécurisé (?.) rend le code concis et lisible. Les seniors adorent quand vous gagnez des lignes sans perdre en clarté. Souvenez-vous : if (x != null) { ... } else { ... } est un faux pas.

2. Extension Functions : « Où sont tes utilitaires ? »

Quand vous voyez une classe utilitaire statique comme StringUtils.capitalize(str), un développeur Kotlin expérimenté va grimacer. Les extension functions sont ce qui rend Kotlin si élégant.

Mauvais exemple

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

Bon exemple

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

Les seniors vous diront : « Pourquoi créer un objet fourre-tout ? Étends simplement la classe ! » Utilisez les extension functions — cela améliore la lisibilité et suit les bonnes pratiques Kotlin.

3. Sealed Classes plutôt que Enum : « Ton enum est dépassé »

Les enum en Kotlin, c'est bien, mais les sealed classes offrent bien plus de flexibilité. Surtout quand il faut stocker différents types de données dans une même hiérarchie.

Mauvais exemple (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}

Bon exemple (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("Données : ${result.data}")\n        is Result.Error -> println("Erreur : ${result.message}")\n        Result.Loading -> println("Chargement...")\n    }\n}

Les développeurs seniors apprécieront que vous utilisiez les sealed classes pour représenter des états. C'est l'un des principaux conseils des seniors Kotlin — rendez les hiérarchies de types explicites.

4. Scope Functions : « Tu as oublié let, apply et run »

Les scope functions (let, apply, run, with, also) sont puissantes