switch Statements and Expressions

When several branches all test the same value, a switch says so directly. An else if chain leaves the reader checking each condition to confirm they are about one thing.

C# has two forms. A switch statement runs different code per case. A switch expression produces a single value. Which one you want depends on that distinction.

string status = "Dispatched";

switch (status)
{
    case "Draft":
        Console.WriteLine("Not submitted yet.");
        break;

    case "Submitted":
    case "Approved":
        Console.WriteLine("Waiting for the warehouse.");
        break;

    case "Dispatched":
        Console.WriteLine("On its way.");
        break;

    default:
        Console.WriteLine($"Unrecognised status: {status}");
        break;
}

• Each case ends with break, which leaves the switch. C# does not allow one case to run on into the next — omit the break and the build fails with "control cannot fall through".
• Two labels stacked together share one block. That is how you say "either of these".
• default catches everything else. Include it: statuses get added over time, and doing nothing quietly is a poor response to one you do not recognise.

decimal orderTotal = 640m;

decimal discountRate = orderTotal switch
{
    >= 1000m => 0.10m,
    >= 500m => 0.05m,
    >= 100m => 0.02m,
    _ => 0m,
};

Console.WriteLine($"Discount rate: {discountRate:P0}");

• The value being tested comes first, then switch, then a list of arms in braces.
• Each arm is a pattern, then =>, then the value it produces. There is no break, because nothing is being executed — the whole construct evaluates to one value.
• >= 1000m is a relational pattern, which is what lets bands be written without a chain of ifs.
• Arms are tried top to bottom and the first match wins, so the largest band has to come first. Put >= 100m at the top and every order gets 2 per cent.
• _ is the catch-all. Leave it out and a value matching no arm throws SwitchExpressionException while the program is running.

object payment = new CardPayment(120m, "VISA");

string summary = payment switch
{
    CardPayment card when card.Amount > 100m => $"Large card payment on {card.Scheme}",
    CardPayment card => $"Card payment on {card.Scheme}",
    BankTransfer transfer => $"Transfer from sort code {transfer.SortCode}",
    null => "No payment recorded",
    _ => "Unrecognised payment type",
};

Console.WriteLine(summary);

public class CardPayment
{
    public CardPayment(decimal amount, string scheme)
    {
        Amount = amount;
        Scheme = scheme;
    }

    public decimal Amount { get; }
    public string Scheme { get; }
}

public class BankTransfer
{
    public BankTransfer(string sortCode)
    {
        SortCode = sortCode;
    }

    public string SortCode { get; }
}

• A type pattern tests the type and gives you a typed variable in one step, so card.Scheme is available inside that arm.
• when adds a further condition to an arm. The narrower arm has to come first — swap the two CardPayment arms and the plain one answers for every card, large or not.
• null is a pattern in its own right. It is the branch people most often leave out, and the one that produces a NullReferenceException later.
• Read top to bottom and you are reading the rules in priority order. That readability is most of the reason to prefer this over an if chain.