Kotlin Boolean? dans if : comment ne pas perdre en performance

Kotlin Boolean? dans if : comment ne pas perdre en performance et ne pas devenir fou

Avez-vous déjà écrit du code en Kotlin et soudainement hésité devant un simple if ? Non pas parce que vous ne savez pas quoi écrire, mais parce que vous avez un Boolean? — une valeur booléenne nullable. Et immédiatement, des centaines de questions vous traversent l'esprit : « Et si c'est null ? Et comment cela affecte-t-il les performances ? Et l'application ne va-t-elle pas planter ? »

Cela vous parle ? Ne vous inquiétez pas, vous n'êtes pas seul. La question « Use of Boolean? in if expression » sur Stack Overflow a recueilli des milliers de vues. Et ce n'est pas un hasard : les types nullables sont l'une des principales fonctionnalités de Kotlin, mais leur mauvaise utilisation peut entraîner des maux de tête et une perte de performance.

Dans cet article, nous allons voir comment travailler correctement avec Boolean? dans les opérateurs conditionnels, quels sont les pièges et comment écrire un code qui soit non seulement sûr, mais aussi rapide. C'est parti !

Qu'est-ce que Boolean? et pourquoi est-ce un problème ?

Pour commencer, rappelons que Boolean? en Kotlin est la version nullable du Boolean standard. Il peut prendre trois valeurs : true, false et null. Une seule valeur supplémentaire, semble-t-il, mais que de tracas !

Le problème survient lorsque vous essayez d'utiliser Boolean? directement dans un if :

val isActive: Boolean? = null

// Erreur de compilation !if (isActive) {    println("Actif")}

Kotlin ne vous le permet pas. Et c'est normal ! Car null dans le contexte de la logique booléenne est une indétermination. Le compilateur vous crie littéralement : « Hé, et si c'est null ? Je ne suis pas médium ! ».

Trois façons de gérer Boolean? dans if

Examinons les principales approches utilisées par les développeurs. Chacune a ses avantages et ses inconvénients, notamment en termes de performance.

1. Vérification explicite de null (la plus sûre)

val isActive: Boolean? = someFunction()

if (isActive == true) {    println("Actif")} else if (isActive == false) {    println("Inactif")} else {    println("Statut non défini")}

Cette approche est la plus lisible et la plus sûre. Vous gérez explicitement les trois états. Mais il y a un bémol : si vous devez seulement vérifier true, et traiter null et false de la même manière, le code devient redondant.

2. Opérateur Elvis ?: (concis mais risqué)

val isActive: Boolean? = someFunction()

if (isActive ?: false) {    println("Actif ou null traité comme false")}

Élégant, n'est-ce pas ? L'opérateur ?: (Elvis) fournit une valeur par défaut si la valeur de gauche est null. Mais il y a un problème caché : vous perdez l'information sur le fait que la valeur était null. Pour la logique métier, cela peut être critique.

3. Fonction let() (style fonctionnel)

val isActive: Boolean? = someFunction()

isActive?.let { value ->    if (value) {        println("Actif")    }}

Ici, let ne s'exécute que si isActive n'est pas null. Le code est joli, mais crée une lambda supplémentaire. Pour les zones à forte charge, cela peut ne pas être optimal.

Performance : mythes et réalité

Vient maintenant la partie la plus intéressante — comment les différentes approches affectent la vitesse d'exécution. Nous avons mené une petite étude (oui, ici sur PythonLib, nous aimons les expériences !).

Que se passe-t-il sous le capot ?

Regardons le bytecode pour différentes variantes. Prenons un exemple simple :

// Variante 1 : vérification expliciteif (isActive == true) { ... }

// Variante 2 : opérateur Elvisif (isActive ?: false) { ... }

Dans le premier cas, Kotlin génère approximativement ce bytecode :

// Pseudo-codeif (isAc