Bien écrire if, else et elseif dans un code lisible

Une structure conditionnelle sert à décider ce qu’un programme doit faire quand la situation change. Si un utilisateur est connecté, l’interface peut afficher son espace. Si un champ obligatoire est vide, le formulaire doit expliquer l’erreur. Si une commande dépasse le stock disponible, le parcours doit bloquer proprement l’achat. Derrière ces exemples simples, if, else et elseif pilotent une grande partie de l’expérience utilisateur, car ils transforment une règle abstraite en comportement visible.

Le vrai enjeu n’est pas de mémoriser une syntaxe par cœur. Il est d’écrire une décision claire, dans le bon ordre, avec des cas limites lisibles. Un code qui choisit bien évite les messages absurdes, les accès trop ouverts, les validations incohérentes et les bugs difficiles à reproduire. Pour une équipe web, une PME ou un produit interne, c’est souvent là que la qualité se joue, surtout lorsque le même parcours doit rester compréhensible après plusieurs évolutions.

Une structure conditionnelle choisit un chemin dans le code

Une structure conditionnelle vérifie une expression qui vaut vrai ou faux, puis exécute le bloc correspondant. Elle permet au programme de prendre un chemin différent selon l’état réel : rôle utilisateur, stock, erreur de saisie, option cochée, date, montant, navigateur ou résultat d’une API. Avant la syntaxe, retenez donc ceci : une condition transforme une situation en décision visible.

Cette définition paraît élémentaire, mais elle évite déjà beaucoup de confusion. Une condition n’est pas une intention. Le programme ne devine pas ce que l’on voulait écrire ; il applique exactement l’expression fournie. Si la règle est ambiguë, inversée ou trop large, le résultat sera logique pour la machine et déroutant pour l’utilisateur, notamment dans les écrans où le visiteur attend une réponse immédiate, comme une validation de compte, un devis ou une confirmation d’achat.

Dans une interface, les conditions contrôlent souvent des moments sensibles : afficher un bouton, autoriser une action, valider un formulaire, calculer des frais, choisir un message d’erreur ou rediriger vers la bonne page. Elles sont donc à la fois techniques et fonctionnelles. Les écrire proprement, c’est protéger le parcours.

La base : if puis else pour couvrir deux cas

Le couple if / else répond à une question binaire. Si la condition est vraie, le premier bloc s’exécute. Sinon, le bloc else prend le relais. Cette forme suffit pour beaucoup de décisions simples : afficher ou masquer, accepter ou refuser, activer ou désactiver, continuer ou interrompre. Commencez donc simple : une question claire, une action si elle passe, un repli si elle échoue.

Voici l’idée en JavaScript, dans un exemple volontairement court :

if (stock > 0) {
  afficherBoutonAchat();
} else {
  afficherMessageIndisponible();
}

Le même raisonnement peut être transposé dans d’autres langages. Python utilise l’indentation pour délimiter les blocs, PHP emploie des accolades dans la forme courante, JavaScript aussi. Ce qui change est la grammaire. Ce qui ne change pas est la question à poser : dans quel cas ce bloc doit-il vraiment s’exécuter, et quel état l’utilisateur doit-il voir si la condition ne passe pas ? Cette question doit rester la même pendant la revue, même si la syntaxe change d’un projet à l’autre.

Un else n’est pas obligatoire. Il devient utile quand le cas inverse doit être explicite. Si rien ne doit se passer lorsque la condition échoue, ajouter un else vide ou artificiel brouille la lecture. À l’inverse, ne pas prévoir de repli peut laisser l’utilisateur sans réponse visible.

La bonne pratique consiste à nommer la règle quand elle devient importante. Une variable comme emailEstValide ou utilisateurPeutPublier vaut souvent mieux qu’une longue combinaison de comparaisons répétée partout. Le code raconte alors une décision, pas seulement une opération.

Else if, elseif ou elif servent à ordonner plusieurs chemins

Quand deux cas ne suffisent plus, on ajoute des branches intermédiaires. JavaScript écrit généralement else if. PHP accepte notamment elseif dans sa documentation. Python utilise elif. Le vocabulaire change, mais le principe reste le même : tester une suite de cas, du plus pertinent au plus général, car plusieurs branches ne sont pas un problème. Un mauvais ordre, si.

L’ordre est décisif, car le programme s’arrête sur la première condition vraie dans une chaîne classique. Si une condition large est placée trop tôt, elle avale les cas plus précis. C’est l’une des erreurs les plus fréquentes dans les validations, les règles de prix et les droits utilisateurs, parce que le bug ne se voit que sur une combinaison précise de valeurs, souvent absente des tests rapides réalisés juste après le développement.

Prenons un seuil de livraison. Si la commande dépasse 150 €, la livraison est offerte. Si elle dépasse 80 €, elle coûte moins cher. Sinon, le tarif normal s’applique. La première condition doit être la plus haute, sinon une commande à 180 € passerait déjà dans le palier à 80 € si la règle large venait avant.

if (montant >= 150) {
  livraison = 'offerte';
} else if (montant >= 80) {
  livraison = 'reduite';
} else {
  livraison = 'standard';
}

Le même piège existe avec les rôles. Un administrateur est souvent aussi un utilisateur connecté. Si le test “utilisateur connecté” arrive avant le test “administrateur”, le code peut afficher une interface trop limitée. Les cas spécifiques doivent donc passer en premier, puis venir le cas général, puis le repli.

Écrivez la condition comme une règle métier

Une condition lisible part du vocabulaire du produit. Au lieu de disperser partout des comparaisons brutes, cherchez le nom qui décrit le choix réel. Un nom clair facilite la revue de code, mais aussi la discussion avec une personne métier : support, direction, marketing, UX, client ou responsable opérationnel. Une bonne condition doit pouvoir être expliquée à quelqu’un qui ne lit pas le langage.

Par exemple, une règle comme clientPeutEtreRelance porte une intention. Elle peut ensuite cacher plusieurs critères : consentement, délai depuis le dernier contact, statut du dossier, pays, canal autorisé. Cette abstraction ne sert pas à masquer la complexité, mais à la placer au bon endroit.

Le seuil critique est celui où la condition ne se relit plus en une respiration. Quand il faut relire trois fois pour comprendre pourquoi une branche passe, la règle mérite probablement un nom, une fonction dédiée ou une séparation en étapes.

C’est le bon moment pour arrêter d’ajouter des parenthèses et revenir à la décision métier que le code doit protéger.

Une condition peut aussi devenir confuse pour une raison plus discrète : elle mélange plusieurs niveaux de décision. Vérifier qu’un compte existe, que son email est confirmé, que son rôle autorise l’action et que la demande respecte un délai ne relève pas toujours du même bloc. Séparer ces niveaux rend le code plus long sur quelques lignes, mais beaucoup plus stable lors des futures corrections, notamment quand une règle de sécurité ou de consentement évolue sans prévenir.

Cette manière de travailler rapproche le code de l’UX. Un message d’erreur, une alerte de formulaire ou un écran vide viennent souvent d’une règle mal exprimée. En écrivant la condition comme une décision utilisateur, on réduit les écarts entre ce que le produit promet et ce que le logiciel affiche.

Les erreurs fréquentes avec if, else et elseif

La première erreur consiste à inverser la condition. Un développeur veut bloquer un accès si l’utilisateur n’est pas autorisé, mais écrit la branche comme si l’autorisation était déjà acquise. Le code fonctionne parfois en test rapide, puis échoue sur le vrai cas limite. Les noms positifs, comme estAutorise, réduisent ce risque, car les bugs de conditions viennent rarement d’un mot-clé inconnu : ils viennent d’une règle mal rangée ou d’une exception traitée trop tard.

La deuxième erreur est l’empilement. Une chaîne de else if peut rester lisible avec trois ou quatre branches. Au-delà, surtout si chaque branche contient beaucoup de code, elle devient difficile à auditer. Le problème n’est pas seulement visuel : une règle oubliée au milieu peut modifier tout le comportement.

La troisième erreur concerne les conditions imbriquées. Un if dans un if dans un autre if force le lecteur à garder plusieurs états en mémoire. On peut parfois simplifier avec un retour anticipé, une fonction dédiée ou une séparation des contrôles. Ce n’est pas une question de style pur ; c’est une question de fiabilité.

La quatrième erreur est le else “fourre-tout”. Il attrape tout ce qui n’a pas été prévu, y compris des états anormaux. Dans un parcours sensible, mieux vaut parfois distinguer le cas attendu et le cas impossible pour afficher une erreur exploitable, enregistrer un log ou bloquer une action. La correction doit rester proportionnée : clarifier la règle vaut mieux que tout réécrire par réflexe.

1. Vérifier chaque branche avec un exemple réel, pas seulement avec une valeur idéale.
2. Tester les limites : égalité, zéro, valeur vide, utilisateur sans rôle, date expirée.
3. Éviter les conditions négatives en cascade si une forme positive est plus claire.
4. Ne pas mélanger validation, calcul et affichage dans une même branche trop longue.

Un bon test manuel consiste à lire la chaîne à voix haute. “Si le client est premium, sinon si le panier dépasse 80 €, sinon tarif standard.” Si la phrase devient confuse, le code le sera aussi. Cette lecture simple repère vite les branches mal ordonnées et les conditions qui devraient être nommées.

Quand remplacer une longue chaîne de conditions

if, else et elseif restent excellents pour une décision lisible. Ils deviennent moins adaptés quand la chaîne commence à simuler une table de correspondance, une machine à états, une matrice de droits ou un calcul configurable. À ce moment, il ne faut pas “interdire” les conditions, mais choisir une structure plus claire, car if / else reste excellent tant qu’il montre la décision au lieu de la cacher, et il devient fragile quand il sert à empiler une politique complète dans un seul bloc.

Une table de configuration convient bien quand une valeur détermine toujours le même résultat : statut, couleur, libellé, niveau de priorité. Une fonction dédiée convient mieux quand la décision rassemble plusieurs critères. Une stratégie ou une machine à états devient utile quand le comportement change fortement selon le contexte.

Deux moments où la logique mérite un support visuel

Visualiser la décision aide à repérer l’ordre des branches et les règles qui devraient sortir du bloc principal.

Dessiner l’arbre avant de coder

Un schéma simple montre les cas acceptés, refusés et intermédiaires avant que la syntaxe ne masque la logique.

Comparer avant / après en revue

Voir une condition imbriquée puis sa version simplifiée aide l’équipe à valider la même règle avec moins de charge mentale.

Le meilleur signal est la modification future. Si chaque nouveau cas oblige à insérer une branche au milieu, à relire tout l’ordre et à craindre une régression, la structure n’est plus assez stable. Il faut alors isoler la règle de décision pour la tester à part.

Cette limite dépend aussi de l’équipe. Une petite équipe sans développeur dédié gagnera parfois à garder une structure explicite et un peu répétitive, tant que les cas restent peu nombreux. À l’inverse, une application produit qui ajoute régulièrement des statuts, des droits ou des offres doit investir plus tôt dans une règle centralisée, sinon chaque évolution devient une chasse aux branches oubliées, avec un risque direct sur le support, la conversion ou la conformité du parcours.

Attention toutefois à ne pas sur-ingénier. Remplacer trois conditions très claires par une architecture abstraite peut rendre le projet moins accessible. Pour une PME qui maintient un outil interne, le code le plus solide est souvent celui qui explique la décision sans demander une carte mentale complète du système.

Une méthode simple pour écrire de meilleures conditions

Commencez par écrire la règle en français avant de coder. “Si le formulaire est incomplet, afficher les champs manquants. Si l’email est invalide, expliquer le format attendu. Si tout est valide, envoyer.” Cette phrase crée la séquence logique avant la syntaxe. La méthode tient en quatre gestes : formuler, illustrer, ordonner, relire côté utilisateur.

1. Nommer le résultat attendu : autoriser, bloquer, afficher, masquer, relancer, calculer ou rediriger.
2. Lister les exemples : un cas vrai, un cas faux, un cas limite et un cas inattendu.
3. Ordonner les branches : exception, cas spécifique, cas courant, repli.
4. Tester la frontière : égalité, montant minimum, rôle absent, valeur vide ou date expirée.

Ensuite, transformez chaque cas en exemple. Un utilisateur connecté, un utilisateur non connecté, un administrateur, un compte suspendu, un stock à zéro, un panier à 79,99 €, un panier à 80 €. Les exemples obligent à regarder les frontières, là où beaucoup de bugs apparaissent.

Enfin, relisez la branche du point de vue de l’utilisateur. Que verra-t-il ? Le bon message ? Le bon bouton ? Le bon état ? Si une condition est juste techniquement mais produit une interface incompréhensible, elle reste à corriger.

Cette méthode paraît lente au début, mais elle évite les corrections dispersées. Une condition bien nommée, testée sur ses limites et reliée au parcours réel se modifie plus facilement. Elle aide aussi les personnes non techniques à comprendre pourquoi une interface réagit de telle manière, ce qui rend les arbitrages plus rapides quand une anomalie remonte depuis le support ou l’équipe commerciale, sans transformer chaque échange en débat sur la syntaxe.

La meilleure condition n’est pas la plus courte ; c’est celle dont le comportement reste évident quand le projet évolue.

Recommandation concrète : pour votre prochaine règle if / else, notez d’abord les trois exemples qui doivent passer et les deux exemples qui doivent échouer. Écrivez ensuite le code. Si vous ne pouvez pas formuler ces cinq cas, la décision n’est pas encore prête à être codée.