Résumé
Après l’épisode sur la sortie de boucle sans violer la règle d’une seule indentation par méthode, celui-ci s’attaque aux conditions imbriquées, la pyramide de la mort, sur deux exemples concrets: trois if emboîtés qui n’agissent que si tout est vrai, et une cascade de if et de else if qui calcule un nombre de jours de congé selon le poste ou le coefficient.
Pour le premier, extraire les conditions dans des variables est possible mais ajoute des tests pour rien. Une petite fonction d’assertion, when, qui exécute une action si sa condition est vraie et renvoie cette condition, permet d’enchaîner les appels: chaque when n’est appelé que si le précédent a renvoyé vrai, et l’imbrication disparaît.
Pour le second, un return par branche aurait fait réagir SonarQube au-delà de trois retours. Les conditions deviennent des accesseurs de classe, puis ces accesseurs renvoient directement le nombre de jours correspondant, et Math.max choisit le résultat: plus aucun if dans la fonction.
Dans les deux cas le code est devenu plus lisible et plus propre, ce qui est le but: du beau code, qui marche. Les tests unitaires ne sont pas montrés ici, mais ils doivent accompagner chaque pas du refactoring.
Idées clés
- Les if imbriqués et les longues cascades de else if cachent l’intention et rendent le code pénible à maintenir.
- Une fonction d’assertion qui renvoie sa condition transforme trois niveaux d’imbrication en une chaîne d’appels.
- Quand chaque branche produit une valeur, des accesseurs qui renvoient cette valeur et un Math.max remplacent tous les branchements.
- Un refactoring sans tests unitaires n’est pas un refactoring, même si l’article ne les montre pas.
Pourquoi j’ai écrit cet article
Dans l’épisode précédent, nous avions vu comment sortir d’une boucle sans violer la règle d’Object Calisthenics «un seul niveau d’indentation par méthode». Cet article traite deux exemples de if imbriqués et explique, pas à pas, comment se débarrasser de toutes ces structures conditionnelles.