if else ב-C#: שרשראות else if, תנאים וטעויות נפוצות

פקודת if מריצה בלוק קוד רק כשתנאי מתקיים. else if מוסיף עוד בדיקות, ו-else תופס את כל מה שהבדיקות לא תפסו.

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)}");
        }
    }
}

פלט:

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

התנאים נבדקים מלמעלה למטה והראשון שמתקיים מנצח. הזמנה של 120 מתאימה ל->= 100 ואף פעם לא מגיעה לבדיקה >= 50, ולכן התנאי הספציפי ביותר בא ראשון. else if היא לא מילת מפתח נפרדת: זה else שהגוף שלו הוא if נוסף, ולכן אין elseif או elif ב-C#.

תנאים חייבים להיות bool

C# אף פעם לא מתייחסת למספר, למחרוזת או לאובייקט כ-true או כ-false. הביטוי שבסוגריים חייב להיות מטיפוס 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

זה מסלק משפחה שלמה של באגים שקיימים ב-C וב-JavaScript, שבהן 0, "" ו-null נחשבים בשקט לשקר. המחיר הוא שכותבים את ההשוואה במפורש בכל פעם, וזה גם הופך את הכוונה לגלויה לקורא הבא.

שילוב תנאים עם &&, || ו-!

&& (וגם), || (או) ו-! (לא) משלבים בדיקות בוליאניות. && ו-|| מבצעים הערכה מקוצרת (short-circuit): הצד הימני רץ רק אם הצד השמאלי עוד לא הכריע את התשובה.

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);
    }
}

פלט:

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

הקריאה עם null בטוחה בזכות ההערכה המקוצרת: ברגע ש-username != null שקרי, username.Length לא מחושב אף פעם, ולכן אין NullReferenceException. החליפו את הסדר ל-username.Length >= 3 && username != null ואותה קריאה קורסת.

ל-&& יש קדימות גבוהה יותר מ-||, ולכן a || b && c פירושו a || (b && c). הוסיפו סוגריים בכל פעם שמערבבים את השניים; הקומפיילר לא צריך אותם, אבל הקוראים כן. גם & ו-| בתו אחד עובדים על bool, אבל הם תמיד מחשבים את שני הצדדים. השתמשו בהם רק כשלצד הימני יש תופעת לוואי שחייבת לקרות.

סוגריים מסולסלים וכלל הפקודה האחת

סוגריים מסולסלים הם אופציונליים כשענף מכיל פקודה אחת. בלעדיהם, רק הפקודה הבאה שייכת ל-if, לא משנה מה ההזחה אומרת:

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}");
    }
}

פלט:

Reorder email sent
Stock: 12

"Reorder email sent" מודפס למרות שהמלאי תקין: ה-WriteLine השני נמצא מחוץ ל-if, למרות ההזחה. שומר של שורה אחת כמו if (x == null) return; בסדר גם בלי סוגריים מסולסלים; כל דבר שעלול לקבל שורה שנייה צריך אותם.

באג קשור הוא נקודה-פסיק מיד אחרי התנאי. if (stock < 5); מסיים את ה-if בפקודה ריקה, והבלוק שבא אחריו רץ בלי תנאי. הקומפיילר מסמן את זה באזהרה CS0642, Possible mistaken empty statement, ששווה להתייחס אליה כשגיאה.

= מול == בתנאי

= מבצע השמה, == משווה. ברוב הטיפוסים, כתיבה של = בטעות לא מתקמפלת, כי התוצאה של השמה היא הערך שהושם ו-int הוא לא bool:

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

עם משתנה bool ההשמה עצמה היא bool, ולכן שגיאת ההקלדה מתקמפלת:

using System;

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

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

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

פלט:

Access granted
isAdmin is now True

התנאי דרס את isAdmin ואז בדק את הערך החדש. הקומפיילר מזהיר (CS0665, השמה בביטוי תנאי היא תמיד קבועה), אבל הבנייה עדיין מצליחה. עבור bool, וותרו על ההשוואה לגמרי: if (isAdmin) ו-if (!isAdmin) קריאים יותר ואי אפשר להקליד אותם לא נכון בצורה הזו.

if מקונן מול guard clauses

כל רמת קינון היא עוד תנאי שהקורא צריך להחזיק בראש. כשכל בדיקה דוחה קלט שגוי, חזרו מוקדם במקום לקנן את המסלול התקין בתוך כולן:

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));
    }
}

פלט:

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

הגרסה המקוננת של אותה מתודה הייתה כוללת שלוש רמות של if, עם העבודה האמיתית בבלוק הפנימי ביותר ושלושה ענפי else שמתפרקים בתחתית. עם guard clauses, כל כלל יושב ליד הודעת השגיאה שלו והשורה האחרונה היא המקרה הרגיל. אותו רעיון עובד בתוך לולאות עם continue.

הצהרה על משתנים בתוך התנאי

תנאי יכול להצהיר על משתנה שנמצא בטווח בתוך ה-if. שתי הצורות הנפוצות הן out var ממתודת TryParse ותבנית הטיפוס עם 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}");
    }
}

פלט:

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

TryParse מחזירה false במקום לזרוק חריגה על קלט שגוי, ולכן היא מתאימה באופן טבעי ל-if. העמוד על המרת טיפוסים מכסה את מתודות הפענוח בפירוט.

מתי להשתמש במשהו אחר

• בחירה של אחד משני ערכים: אופרטור התנאי condition ? a : b קצר יותר מ-if שמבצע השמה בשני הענפים.
• הרבה ענפים על ערך אחד: פקודת switch משווה ערך מול מקרים קבועים, וקל יותר לסרוק אותה מאשר עשר שורות של else if.
• מיפוי של ערך לתוצאה: חיפוש ב-Dictionary מחליף שרשרת ארוכה כשהענפים שונים רק בנתונים.