Top des erreurs des développeurs Kotlin débutants : de A à Z

Top erreurs des développeurs Kotlin débutants : de A à Z

Kotlin est un langage moderne, concis et sûr qui a rapidement conquis le cœur des développeurs Android et des ingénieurs backend. Cependant, même dans un langage aussi convivial, les débutants commettent souvent des erreurs typiques qui ralentissent l'apprentissage et entraînent des bugs. Dans cet article, nous allons passer en revue les problèmes les plus courants — de la mauvaise compréhension de la null safety à l'abus de lateinit. Vous apprendrez comment les éviter et écrire un code Kotlin propre et efficace.

1. Ignorer la null safety et mauvaise gestion des types nullable

L'un des principaux atouts de Kotlin est la protection intégrée contre les NullPointerException. Mais les débutants essaient souvent d'utiliser l'approche Java, ce qui entraîne des erreurs.

Erreur : Utilisation de !! (non-null assertion) là où ce n'est pas nécessaire

Beaucoup écrivent :

fun getUserName(user: User?): String {    return user!!.name // Si user == null — NPE}

Il est préférable d'utiliser l'appel sécurisé (?.) ou l'opérateur Elvis (?:) :

fun getUserName(user: User?): String {    return user?.name ?: "Invité"}

Erreur : Utilisation incorrecte de lateinit var

Le champ lateinit est destiné aux situations où vous savez avec certitude que la variable sera initialisée avant sa première utilisation (par exemple, dans Android dans onCreate). Mais si vous accédez à lateinit avant l'initialisation, vous obtiendrez une UninitializedPropertyAccessException.

Conseil : Utilisez lateinit uniquement avec var et vérifiez la propriété ::variable.isInitialized avant d'y accéder.

2. Mauvaise utilisation des collections : mutables vs immutables

Kotlin distingue clairement List (lecture seule) et MutableList. Les débutants les confondent souvent, ce qui entraîne des erreurs de compilation ou un comportement inattendu.

Erreur : Tentative de modification d'une liste immuable

val list = listOf(1, 2, 3)list.add(4) // Erreur de compilation ! listOf retourne List, pas MutableList

Si vous avez besoin d'une collection mutable, utilisez mutableListOf :

val mutableList = mutableListOf(1, 2, 3)mutableList.add(4) // Fonctionne

Erreur : Retourner une MutableList depuis une API publique

Cela viole l'encapsulation. Il est préférable de retourner une List :

// Mauvaisfun getItems(): MutableList<String> = mutableListOf("a", "b")

// Bonfun getItems(): List<String> = mutableListOf("a", "b").toList()

3. Abus du companion object au lieu des fonctions top-level

Kotlin n'a pas de méthodes statiques, mais il a le companion object. Les débutants y mettent souvent tout et n'importe quoi, alors qu'il est possible d'utiliser des fonctions ou propriétés top-level plus concises.

Exemple d'erreur :

class Utils {    companion object {        fun formatDate(date: Date): String { ... }    }}

// Appel : Utils.formatDate(...)

Il est préférable de placer la fonction au niveau du fichier :

// file: DateUtils.ktfun formatDate(date: Date): String { ... }

// Appel : formatDate(...)

Cela rend le code plus propre et ne nécessite pas la création d'une classe supplémentaire. Utilisez companion object uniquement pour les méthodes factory ou les constantes liées à la classe.

4. Incompréhension des sealed classes et des expressions when

Les sealed classes sont un outil puissant pour représenter une hiérarchie de types restreinte. Cependant, les débutants oublient souvent la branche else ou utilisent if-else au lieu de when, perdant ainsi tous les avantages.

Erreur : Utilisation de else dans when pour une sealed class

sealed class Result {    data class Success(val data: String) : Result()    data