if else en C# : chaînes else if, conditions et erreurs courantes

Une instruction if n'exécute un bloc de code que lorsqu'une condition est vraie. else if ajoute d'autres tests, et else attrape tout ce que les tests n'ont pas couvert.

using System;

class Program
{
    static decimal ShippingCost(decimal orderTotal)
    {
        if (orderTotal >= 100m)
        {
            return 0m;
        }
        else if (orderTotal >= 50m)
        {
            return 4.99m;
        }
        else
        {
            return 9.99m;
        }
    }

    static void Main()
    {
        decimal[] totals = { 120m, 75.50m, 20m };
        foreach (decimal t in totals)
        {
            Console.WriteLine($"Order {t}: shipping {ShippingCost(t)}");
        }
    }
}

Sortie :

Order 120: shipping 0
Order 75.50: shipping 4.99
Order 20: shipping 9.99

Les conditions sont vérifiées de haut en bas et la première vraie l'emporte. Une commande de 120 correspond à >= 100 et n'atteint jamais le test >= 50, c'est pourquoi la condition la plus spécifique vient en premier. else if n'est pas un mot-clé distinct : c'est un else dont le corps est un autre if, il n'y a donc ni elseif ni elif en C#.

Les conditions doivent être des bool

C# ne traite jamais un nombre, une chaîne ou un objet comme vrai ou faux. L'expression entre parenthèses doit être de type bool :

int count = 3;
if (count)          // error CS0029: Cannot implicitly convert type 'int' to 'bool'
if (count > 0)      // correct
if (name)           // error: a string is not a bool either
if (name != null)   // correct

Cela supprime toute une famille de bugs de C et JavaScript, où 0, "" et null comptent silencieusement comme faux. Le prix à payer est d'écrire la comparaison à chaque fois, ce qui rend aussi l'intention visible pour le lecteur suivant.

Combiner des conditions avec &&, || et !

&& (et), || (ou) et ! (non) combinent des tests booléens. && et || court-circuitent : la partie droite ne s'exécute que si la partie gauche n'a pas déjà décidé du résultat.

using System;

class Program
{
    static void Check(string username, int age, bool banned)
    {
        if (username != null && username.Length >= 3 && !banned)
        {
            if (age < 13 || age > 120)
            {
                Console.WriteLine($"{username}: age {age} rejected");
            }
            else
            {
                Console.WriteLine($"{username}: welcome");
            }
        }
        else
        {
            Console.WriteLine("invalid or banned account");
        }
    }

    static void Main()
    {
        Check("maya", 29, false);
        Check("li", 40, false);
        Check(null, 25, false);
        Check("omar", 9, false);
        Check("jonas", 31, true);
    }
}

Sortie :

maya: welcome
invalid or banned account
invalid or banned account
omar: age 9 rejected
invalid or banned account

L'appel avec null est sûr grâce au court-circuit : dès que username != null est faux, username.Length n'est jamais évalué, donc pas de NullReferenceException. Inversez l'ordre en username.Length >= 3 && username != null et le même appel plante.

&& lie plus fortement que ||, donc a || b && c signifie a || (b && c). Ajoutez des parenthèses dès que vous mélangez les deux ; le compilateur n'en a pas besoin, mais les lecteurs si. Les opérateurs à un caractère & et | fonctionnent aussi sur bool, mais ils évaluent toujours les deux côtés. Ne les utilisez que lorsque la partie droite a un effet de bord qui doit se produire.

Les accolades et la règle de l'instruction unique

Les accolades sont facultatives quand une branche contient une seule instruction. Sans elles, seule l'instruction suivante appartient au if, quoi qu'en dise l'indentation :

using System;

class Program
{
    static void Main()
    {
        int stock = 12;

        if (stock < 5)
            Console.WriteLine("Low stock, reordering");
            Console.WriteLine("Reorder email sent");

        Console.WriteLine($"Stock: {stock}");
    }
}

Sortie :

Reorder email sent
Stock: 12

« Reorder email sent » s'affiche alors que le stock est suffisant : le second WriteLine est en dehors du if, malgré l'indentation. Une garde sur une ligne comme if (x == null) return; convient sans accolades ; tout ce qui pourrait gagner une seconde ligne devrait en avoir.

Un bug voisin est un point-virgule juste après la condition. if (stock < 5); termine le if par une instruction vide, et le bloc qui suit s'exécute sans condition. Le compilateur le signale par l'avertissement CS0642, Possible mistaken empty statement, qu'il vaut la peine de traiter comme une erreur.

= ou == dans une condition

= affecte, == compare. Pour la plupart des types, écrire = par erreur ne compile pas, car le résultat d'une affectation est la valeur affectée et un int n'est pas un bool :

int score = 10;
if (score = 100) { }   // error CS0029: Cannot implicitly convert type 'int' to 'bool'

Avec une variable bool, l'affectation est elle-même un bool, donc la faute de frappe compile :

using System;

class Program
{
    static void Main()
    {
        bool isAdmin = false;

        if (isAdmin = true)
        {
            Console.WriteLine("Access granted");
        }

        Console.WriteLine($"isAdmin is now {isAdmin}");
    }
}

Sortie :

Access granted
isAdmin is now True

La condition a écrasé isAdmin puis testé la nouvelle valeur. Le compilateur émet un avertissement (CS0665, assignment in a conditional expression is always constant), mais la compilation réussit quand même. Pour les bool, passez-vous complètement de la comparaison : if (isAdmin) et if (!isAdmin) se lisent mieux et ne peuvent pas être mal tapés de cette façon.

if imbriqués ou clauses de garde

Chaque niveau d'imbrication est une condition de plus que le lecteur doit garder en tête. Quand chaque vérification rejette une entrée invalide, sortez tôt au lieu d'imbriquer le cas normal dans toutes ces vérifications :

using System;

class Program
{
    static string PlaceOrder(string product, int quantity, decimal balance, decimal price)
    {
        if (string.IsNullOrEmpty(product))
            return "error: no product";
        if (quantity <= 0)
            return "error: quantity must be positive";
        if (balance < price * quantity)
            return "error: insufficient balance";

        return $"ordered {quantity} x {product}";
    }

    static void Main()
    {
        Console.WriteLine(PlaceOrder("keyboard", 2, 100m, 35m));
        Console.WriteLine(PlaceOrder("", 1, 100m, 35m));
        Console.WriteLine(PlaceOrder("mouse", 0, 100m, 20m));
        Console.WriteLine(PlaceOrder("monitor", 1, 100m, 180m));
    }
}

Sortie :

ordered 2 x keyboard
error: no product
error: quantity must be positive
error: insufficient balance

La version imbriquée de la même méthode aurait trois niveaux de if, avec le vrai travail dans le bloc le plus interne et trois branches else qui se dénouent en bas. Avec des clauses de garde, chaque règle se trouve à côté de son message d'erreur et la dernière ligne est le cas normal. La même idée fonctionne dans les boucles avec continue.

Déclarer des variables dans la condition

Une condition peut déclarer une variable visible à l'intérieur du if. Les deux formes courantes sont un out var provenant d'une méthode TryParse et le pattern de type is :

using System;

class Program
{
    static void Main()
    {
        string[] inputs = { "42", "abc", "-7" };
        foreach (string s in inputs)
        {
            if (int.TryParse(s, out var n) && n > 0)
                Console.WriteLine($"{s}: positive number {n}");
            else if (int.TryParse(s, out n))
                Console.WriteLine($"{s}: number {n}, not positive");
            else
                Console.WriteLine($"{s}: not a number");
        }

        object value = "hello";
        if (value is string text)
            Console.WriteLine($"string of length {text.Length}");
    }
}

Sortie :

42: positive number 42
abc: not a number
-7: number -7, not positive
string of length 5

TryParse renvoie false au lieu de lever une exception sur une entrée invalide, ce qui en fait le partenaire naturel d'un if. La page sur la conversion de types détaille les méthodes d'analyse.

Quand utiliser autre chose

• Choisir l'une de deux valeurs : l'opérateur conditionnel condition ? a : b est plus court qu'un if qui affecte dans les deux branches.
• Beaucoup de branches sur une seule valeur : une instruction switch compare une valeur à des cas constants et se parcourt plus facilement que dix lignes else if.
• Associer une valeur à un résultat : une recherche dans un Dictionary remplace une longue chaîne quand les branches ne diffèrent que par des données.