L'opérateur ternaire en Kotlin : 5 erreurs principales des débutants

L'opérateur ternaire en Kotlin : pourquoi il n'existe pas et comment éviter les pièges

Si vous venez en Kotlin depuis Java, C# ou JavaScript, vous vous êtes sûrement déjà surpris à penser : « Où est mon opérateur ternaire préféré condition ? valeur1 : valeur2 ? ». Spoiler : il n'existe pas en Kotlin. Et ce n'est pas un bug, mais une fonctionnalité. Les développeurs du langage ont estimé que le ternaire classique était une entité superflue qui ne fait que compliquer la lecture du code, surtout lorsque les conditions imbriquées deviennent plus de deux.

Mais l'absence d'opérateur ternaire n'est pas un problème. Kotlin propose des alternatives bien plus flexibles et sûres. Cependant, les débutants (et même les développeurs expérimentés) commettent souvent les mêmes erreurs en essayant d'émuler la construction habituelle. Dans cet article, nous allons analyser le top 5 des erreurs lors de l'utilisation des expressions conditionnelles en Kotlin et montrer comment les éviter. C'est parti !

Erreur n°1 : Essayer d'insérer l'opérateur ternaire « à la volée »

L'erreur la plus courante est d'écrire du code à la Java :

// ❌ Erreur : cette syntaxe n'existe pas en Kotlin\nval max = (a > b) ? a : b\n

Kotlin ne compilera tout simplement pas ce code. Vous obtiendrez l'erreur : Unresolved reference: ?. De nombreux développeurs sont alors bloqués et commencent à chercher des bibliothèques ou des plugins qui « ajoutent » l'opérateur ternaire. Ne faites pas cela !

Comment faire correctement ?

En Kotlin, if n'est pas un opérateur, mais une expression. Elle retourne une valeur. Donc, au lieu du ternaire, utilisez un simple if-else :

// ✅ Manière correcte : if comme expression\nval max = if (a > b) a else b\n

Le code se lit même plus facilement que le ternaire classique, surtout si la condition est complexe. Souvenez-vous : if en Kotlin retourne toujours la dernière valeur de chaque branche.

Erreur n°2 : Oublier le else lors de l'affectation

Puisque if est une expression, elle doit retourner une valeur. Si vous écrivez :

// ❌ Erreur : pas de else, le compilateur ne sait pas quoi retourner\nval result = if (condition) "Oui"\n

Le compilateur générera une erreur : All branches of 'if' expression are required to return a value. C'est logique : que devrait contenir result si la condition est fausse ? null ? Une chaîne vide ? Le compilateur ne devine pas.

Comment faire correctement ?

Ajoutez toujours un else :

// ✅ Correct : les deux branches retournent une valeur\nval result = if (condition) "Oui" else "Non"\n

Exception : si vous utilisez if comme instruction (sans affectation), alors else n'est pas obligatoire :

// if instruction — else non nécessaire\nif (condition) {\n    println("Oui")\n}\n

Erreur n°3 : Des if-else imbriqués complexes au lieu de when

Lorsque vous avez plus de deux options, une chaîne de if-else if-else se transforme en « spaghetti ». Regardez cette horreur :

// ❌ Mauvais : les if-else imbriqués sont difficiles à lire\nval status = if (code == 200) "OK"\n            else if (code == 404) "Non trouvé"\n            else if (code == 500) "Erreur serveur"\n            else "Inconnu"\n

Les lignes sautent, les yeux s'égarent. Et si vous ajoutez encore quelques conditions, ce sera un cauchemar.

Comment faire correctement ?

Utilisez when — c'est l'équivalent d'un switch sous stéroïdes :

// ✅ Excellent : when se lit comme un tableau\nval status = when (code) {\n    200 -> "OK"\n    404 -> "Non trouvé"\n    500 -> "Erreur serveur"\n    else -> "Inconnu"\n}\n

when en Kotlin est également une expression, il peut donc retourner une valeur. Et il est bien plus clair qu'une chaîne de if-else. De plus, when supporte des conditions complexes : plages, types, expressions arbitraires.

// when avec une plage\nval grade = when (score) {\n    i