Introduction : pourquoi Kotlin semble facile mais réserve des surprises
\n\nKotlin est un langage moderne, concis et incroyablement pratique. De nombreux débutants viennent du Java ou du Python en pensant : « Bon, là, tout est clair ! ». Et effectivement, la syntaxe de Kotlin est propre, les types nullable protègent des NPE, et les fonctionnalités fonctionnelles comme let, apply et run semblent magiquement simples. Mais c'est précisément cette simplicité apparente qui devient souvent un piège.
Dans cet article, nous allons décortiquer les erreurs les plus courantes lors de l'apprentissage de Kotlin que commettent les débutants. Vous apprendrez à les éviter et obtiendrez des exemples de code prêts à l'emploi. Si vous débutez votre parcours en Kotlin pour débutants, cet article vous épargnera des heures de débogage.
\n\nErreur n°1 : Ignorer la null safety ou, à l'inverse, devenir paranoïaque
\n\nKotlin intègre la null safety directement dans son système de types. C'est un atout, mais les débutants tombent souvent dans deux extrêmes. Le premier : ignorer complètement la sécurité et utiliser l'opérateur !! (not-null assertion) à tout va. Le second : abuser de l'opérateur Elvis ?: et des chaînes de ?.let qui transforment le code en un plat de spaghettis illisible.
À quoi ressemble l'erreur
\n\n// Mauvais : le !! systématique tue toute la sécurité de Kotlin\nfun processUser(user: User?) {\n val name = user!!.name // Si user == null — crash !\n println(name.uppercase())\n}\n\n// Mauvais : trop de let imbriqués\nfun getUserCity(user: User?): String? {\n return user?.let {\n it.address?.let { addr ->\n addr.city?.let { city ->\n city.name\n }\n }\n }\n}\n\n\nLa bonne pratique
\n\n// Bien : utilisation de l'appel sécurisé + Elvis\nfun processUserSafe(user: User?) {\n val name = user?.name ?: "Invité"\n println(name.uppercase())\n}\n\n// Excellent : extensions et fonctions de portée sans jungle d'imbrications\nfun getUserCityClean(user: User?): String? {\n return user?.address?.city?.name\n}\n\n\nConseil : N'utilisez l'opérateur !! que si vous êtes sûr à 100 % que la valeur n'est pas null (par exemple, après une vérification dans un if). Dans tous les autres cas, privilégiez ?. et ?:.
C'est l'un des principaux problèmes des débutants en Kotlin : ils ont soit peur de null, soit ne comprennent pas comment le gérer. Souvenez-vous : Kotlin n'interdit pas null, il vous oblige à y réfléchir.
\n\nErreur n°2 : Ne pas comprendre la différence entre var, val et les constantes
\n\nOn pourrait croire que val est une variable finale, comme final en Java. Mais non. val est une référence en lecture seule, pas un objet immuable. Les débutants confondent souvent val avec une constante de compilation (const val) et s'étonnent que leur code ne fonctionne pas comme prévu.
Exemple de confusion
\n\n// Le débutant pense : "val = immuable"\nval list = mutableListOf(1, 2, 3)\nlist.add(4) // Ça marche ! Mais le débutant est choqué\n\n// Par contre, ceci est une erreur de compilation\nval name = "Alice"\nname = "Bob" // Erreur : val ne peut pas être réaffecté\n\n\nComment faire la différence
\n\n// Constante de compilation — uniquement pour les primitifs et String\nconst val PI = 3.14159\n\n// Référence en lecture seule — peut être calculée à l'exécution\nval currentTime = System.currentTimeMillis()\n\n// Véritable immuabilité — utilisez des collections immuables\nval immutableList = listOf(1, 2, 3) // listOf, pas mutableListOf\n\n\nRègle d'or : Utilisez val partout où c'est possible. Si une variable doit changer, alors seulement utilisez var. Et const val uniquement pour les constantes de niveau supérieur ou à l'intérieur d'un object/companion object.
Erreur n°3 : Abuser de companion object et des singletons object
\n\nKotlin offre une manière élégante de créer des singletons via ob