Top erreurs des développeurs Kotlin débutants : niveau avancé

Top erreurs des développeurs Kotlin débutants : niveau avancé

Kotlin est un langage moderne et concis qui remplace activement Java dans le développement Android et le backend. Cependant, sa flexibilité joue souvent un mauvais tour aux débutants qui y passent après d'autres langages. Dans cet article, nous analyserons les erreurs non évidentes mais critiques que commettent les développeurs ayant déjà maîtrisé la syntaxe de base. Vous apprendrez à éviter les problèmes avec les coroutines, les classes sealed, les fonctions inline et les propriétés déléguées. Chaque section contient des exemples de code concrets et des recommandations.

1. Mauvaise utilisation des coroutines : fuites mémoire et perte de contexte

Les coroutines sont un outil puissant pour l'asynchrone, mais leur mauvaise application entraîne des fuites mémoire et des bugs difficiles à détecter. L'erreur la plus fréquente est le lancement d'une coroutine sans la lier au cycle de vie du composant.

Erreur : scope global dans une Activity

// MAUVAIS : la coroutine vit plus longtemps que l'Activityclass MyActivity : AppCompatActivity() {    fun loadData() {        GlobalScope.launch {            val data = fetchFromNetwork()            withContext(Dispatchers.Main) {                textView.text = data // Fuite si l'Activity est déjà détruite            }        }    }}

Solution : utilisation de lifecycleScope ou viewModelScope

// BON : la coroutine est annulée lors de la destruction de l'Activityclass MyActivity : AppCompatActivity() {    fun loadData() {        lifecycleScope.launch {            val data = withContext(Dispatchers.IO) { fetchFromNetwork() }            textView.text = data        }    }}

Conseil : Utilisez toujours un CoroutineScope lié au cycle de vie. Pour ViewModel — viewModelScope, pour Activity/Fragment — lifecycleScope. N'utilisez jamais GlobalScope en production.

2. Abus de la null safety : hypothèses implicites

Kotlin est réputé pour sa null safety, mais les débutants créent souvent un faux sentiment de sécurité. L'erreur est d'utiliser l'opérateur !! là où des appels sécurisés suffisent.

Erreur : ignorer les types nullable

// MAUVAIS : peut lever une NullPointerExceptionfun processUser(user: User?) {    val name = user!!.name    println(name)}

Solution : utilisation de l'opérateur Elvis ou de let

// BON : extraction sécuriséefun processUser(user: User?) {    val name = user?.name ?: "Inconnu"    println(name)        // Ou avec let :    user?.let { u ->        println(u.name)    }}

Important : L'opérateur !! n'est justifié que dans les tests ou lorsque vous êtes sûr à 100% que la valeur n'est pas null (par exemple, après une vérification dans un if). Dans les autres cas, utilisez ?.let, ?: ou requireNotNull().

3. Mauvaise utilisation des classes sealed et de when

Les classes sealed sont un excellent moyen de modéliser des hiérarchies limitées. Cependant, les débutants oublient souvent que when peut être une expression et ne prennent pas en compte toutes les branches.

Erreur : omission de branches dans when

sealed class Result {    data class Success(val data: String) : Result()    data class Error(val message: String) : Result()    object Loading : Result()}

// MAUVAIS : le compilateur ne préviendra pas de l'absence de Loadingfun handleResult(result: Result) {    when (result) {        is Result.Success -> println(result.data)        is Result.Error -> println(result.message)        // Loading oublié !    }}

Solution : utilisation de when comme expression

// BON : le compilateur forcera le traitement de toutes les branchesfun handleResult(result: Result): String {    return when (result) {        is Result.Success -> result.data        is Result.Error -> result.message        is Result.Loa