Code Review Kotlin : 7 pièges qui ruinent votre projet

Pourquoi le code review sur Kotlin ne se résume pas à "j'aurais écrit ça autrement" ?

Le code review (ou revue de code) est un rituel sacré dans toute équipe qui se respecte. Mais quand il s'agit de Kotlin, de nombreux développeurs sont perplexes. "Tout est si concis ici !", "C'est un langage expression-based" — pensez-vous en parcourant une pull request. Et vous avez tort.

Kotlin est élégant, mais perfide. Il vous offre des outils puissants : les scope functions, les sealed classes, les coroutines. Et tout autant d'opportunités de vous tirer une balle dans le pied. Dans cet article, nous allons voir ce qu'il faut vraiment vérifier lors d'un code review Kotlin pour que votre code ne devienne pas un "monstre spaghetti" avec des effets de bord nullables.

Cet article n'est pas un manuel de syntaxe. C'est une checklist vivante pour le relecteur qui veut voir non seulement un code fonctionnel, mais un produit maintenable et sécurisé.

1. Null Safety : quand "?" n'est pas une panacée

Kotlin est fier de sa Null Safety. Et il a raison. Mais lors d'un code review, vous devez vérifier non seulement la présence de "!!", mais aussi la logique de gestion des types nullable.

Qu'est-ce qui doit absolument vous alerter ?

\n
• L'utilisation incontrôlée de "!!". Si un développeur utilise !!, il doit expliquer dans un commentaire pourquoi cette valeur est garantie non nulle. Sans explication, c'est un bug.
\n
• Les chaînes d'appels safe call (?.) et elvis (?:). Elles masquent souvent des erreurs logiques. Exemple :
\n

// Problème : si user?.address?.city == null,\n// on retourne "Unknown" sans aucun log\nval city = user?.address?.city ?: "Unknown"\n

Comment faire ? Si null est une situation exceptionnelle, utilisez requireNotNull ou checkNotNull. Si c'est un comportement normal, loggez-le.

val city = user?.address?.city\n    ?: run {\n        logger.warn("L'utilisateur $userId n'a pas de ville")\n        "Unknown"\n    }\n

Lors d'un code review Kotlin, demandez toujours : "Et si ce null est un bug que nous venons d'ignorer ?"

2. Scope functions : let, apply, run — utilisez-les avec discernement

Les scope functions sont la puissance de Kotlin. Mais en pratique, je les vois utilisées comme un marteau pour tous les clous. La revue de code Kotlin doit inclure l'analyse : "Pourquoi let ici plutôt que run ?"

Pièges typiques :

\n
• let pour vérifier la nullité. OK, mais ne les imbriquez pas les uns dans les autres :
\n

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

\n
• apply pour muter un objet. C'est son usage naturel. Mais si vous utilisez apply à l'intérieur d'un let — stop. Ça sent le spaghetti.
\n

Rappelez-vous : with pour grouper des appels, also pour les effets de bord (logging), run pour les calculs dans un contexte. Ne les confondez pas.

3. Immuabilité : var est un chiffon rouge

Kotlin prône val. Et c'est excellent. Mais lors d'une revue de code Kotlin, je vois souvent des développeurs utiliser var là où val avec copie suffirait.

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

Règle simple : si vous voyez var, demandez : "Pourquoi pas val ?" La réponse vous surprendra souvent : "Je n'y ai pas pensé."

Exception : uniquement si la mutation est vraiment nécessaire (par exemple, dans des boucles d'accumulation). Mais même là, on peut souvent la remplacer par fold ou reduce.

4. Sealed classes et when : n'oubliez pas le else

Les sealed classes sont une alternative élégante. Mais attention : si vous utilisez when avec des sealed classes, Kotlin vous permet d'omettre else si tous les cas sont couverts. Cependant, si vous ajoutez un nouveau sous-type plus tard, le compilateur ne vous avertira pas si vous avez un else générique. Préférez toujours une couverture exhaustive sans else pour bénéficier de la vérification à la compilation.