Revue de code en Kotlin : que vérifier et comment donner un retour

Revue de code en Kotlin : quoi vérifier et comment donner un retour

La revue de code est l'un des outils les plus efficaces pour maintenir la qualité du code, partager les connaissances au sein d'une équipe et prévenir les bogues. Cependant, simplement "jeter un coup d'œil" à une pull request ne suffit pas. Dans le langage Kotlin, avec son système de types riche, ses coroutines et ses capacités fonctionnelles, il est important de prêter attention à des points spécifiques. Dans cet article, nous allons détailler quoi exactement rechercher lors de la revue de code Kotlin, et comment formuler des commentaires pour qu'ils soient bénéfiques plutôt que blessants.

1. Principes de base d'un retour constructif

Avant de passer aux détails techniques, rappelons quelques règles qui rendent la revue de code utile pour tous les participants.

Concentrez-vous sur le code, pas sur l'auteur

Au lieu de "Vous avez écrit du mauvais code", dites "Cette méthode peut être simplifiée en utilisant let". La spécificité et un ton neutre réduisent les tensions.

Catégorisation

Marquez les commentaires comme :

• Bloquant — doit être corrigé (erreur logique, fuite de ressources).
• Nitpick — détails mineurs (style, formatage).
• Question — clarification (l'intention n'est pas claire).

Expliquez le "pourquoi"

Il ne suffit pas de dire "utilisez filterNotNull()". Ajoutez : "Cela éliminera une boucle inutile et rendra le code auto-documenté". Ainsi, l'auteur apprend, et pas seulement corrige.

2. Sécurité null et types : les principaux alliés de Kotlin

Kotlin est conçu pour éviter les NullPointerException à la compilation. Vérifiez que cette protection n'est pas compromise.

Évitez les !! (assertion non-nulle) inutiles

L'opérateur !! est un appel à l'aide. Son utilisation doit être l'exception, pas la règle.

// Mauvais : risque de NPEfun process(user: User?) {    val name = user!!.name}

// Bon : appel sécuriséfun process(user: User?) {    val name = user?.name ?: "Invité"}

Quoi vérifier : si vous voyez !!, demandez à l'auteur s'il peut être remplacé par ?.let, ?: (elvis), ou requireNotNull().

Utilisation correcte des types nullables

Tous les paramètres n'ont pas besoin d'être nullables. Si une fonction attend toujours une valeur, déclarez le type sans point d'interrogation.

// Discutable : null ne signifie rienfun log(message: String?) {    println(message ?: "null")}

// Meilleur : exigence explicitefun log(message: String) {    println(message)}

3. Coroutines et threads : async sans douleur

Les coroutines Kotlin sont un outil puissant, mais elles sont faciles à mal utiliser. Lors de la revue, faites attention aux points suivants.

Dispatcheur correct pour les tâches

N'exécutez pas d'opérations longues (réseau, disque) sur Dispatchers.Main.

// Mauvais : bloque l'UIGlobalScope.launch(Dispatchers.Main) {    val data = fetchFromNetwork() // se bloque}

// Bon : changement de contexteviewModelScope.launch {    val data = withContext(Dispatchers.IO) {        fetchFromNetwork()    }    updateUI(data)}

Fuites de coroutines et concurrence structurée

Utilisez viewModelScope, lifecycleScope, ou coroutineScope au lieu de GlobalScope. Ce dernier vit aussi longtemps que l'application et conduit facilement à des fuites.

// Dangereux : fuiteGlobalScope.launch { /* ... */ }

// Sûr : lié au cycle de videlifecycleScope.launch { /* ... */ }

4. Collections et style fonctionnel : concision et lisibilité

Kotlin offre une bibliothèque riche pour travailler avec les collections. Utilisez-la au lieu de boucles explicites.

Chaînes d'opérations au lieu de mutations

Évitez d'ajouter manuellement à une liste si vous pouvez collecter le résultat en utilisant une chaîne d'opérations.