Should I use switch statements or long if...else chains?

Question

Often when I hear about the switch statement, its put off as a way to replace long if...else chains. But it seems that when I use the switch statement I'm writing more code that I would be just writing if...else. You also have other issues like keeping all variables for all calls in the same scope.

Here's some code that represents the flow I normally write (thanks to diam)

String comment;   // The generated insult.
int which = (int)(Math.random() * 3);  //  Result is 0, 1, or 2.

if (which == 0) {
    comment = "You look so much better than usual.";
} else if (which == 1) {
    comment = "Your work is up to its usual standards.";
} else if (which == 2) {
    comment = "You're quite competent for so little experience.";
} else {
    comment = "Oops -- something is wrong with this code.";
}

Then they want me to replace that with this:

String comment;   // The generated insult.
int which = (int)(Math.random() * 3);  //  Result is 0, 1, or 2.

switch (which) {
    case 0:  
             comment = "You look so much better than usual.";
    break;
    case 1:  
             comment = "Your work is up to its usual standards.";
    break;
    case 2:  
             comment = "You're quite competent for so little experience.";
    break;
    default: 
             comment = "Oops -- something is wrong with this code.";
}

Seems like a lot more code in a much more awkward syntax. But is there really an advantage to using the switch statement?

Answer 1

For this particular situation, it seems to me that both if and case are poor choices. I'd use a simple array:

String comments[] = {
    "You look so much better than usual.",
    "Your work is up to its usual standards.",
    "You're quite competent for so little experience."
};

String comment = comments[(int)(Math.random() * 3)];

As a side note, you should generally compute the multiplier based on the size of the array rather than hard-coding the 3.

As to when you would use a case/switch, the difference from a cascade of if statements (or at least one major difference) is that switch can semi-automatically optimize based on the number and density of values, whereas a cascade of if statements leaves the compiler with little choice but to generate code as you've written it, testing one value after another until it finds a match. With only three real cases, that's hardly a concern, but with a sufficient number it can/could be significant.

Answer 2

The problem with the if...else if... chain is that when I come along to read it, I have to look at every single if condition to understand what the program is doing. For example, you might have something like this:

if (a == 1) {
    // stuff
} else if (a == 2) {
    // stuff
} else if (a == 3) {
    // stuff
} else if (b == 1) {
    // stuff
} else if (b == 2) {
    // stuff
}

(obviously, for a small number of statements like this, it's not so bad)

I'd have no way of knowing that you changed condition variable half-way through without reading every single statement. However, because a switch limits you to a single condition variable only, I can see at a glance what's happening.

At the end of the day, though, I'd prefer neither switch or a chain of if...else if. Often a better solution is some kind of jump table or dictionary for cases like in the original question, or polymorphism (if your language supports that). It's not always possible, of course, but I'd look for a solution that avoids switch as a first step...

Answer 3

switch (which) {
  case 0: comment = "String 1"; break;
  case 1: comment = "String 2"; break;
  case 2: comment = "String 3"; break;
  default: comment = "Oops"; break;
}

The above way of writing this type of switch case is fairly common. The reason why you felt the switch case if bulkier is because your body was only one line and with a switch case you also needed the break statement. So the switch case had twice the body size of if else. With more substantial code, the break statement will not add much to the body. For single line body, it is a common practice to write the code in the same line as the case statement.

As others have already mentioned, a switch case makes the intent more clear, you want to make a decision based on the value of a single variable/expression. My comments are purely from a readability point of view and not performance based.

Answer 4

In this case the switch statement more clearly matches the intent of the code: pick an action to take based on a single value.

The if statements on the other hand are much harder to read - you have to look at all of them to be sure what's going on. To me it's less code (even if the character count may be slightly higher) as there's less to mentally parse.

Answer 5

I agree with Jerry that an array of strings is better for this particular case, but that in general it's better to use a switch/case statement than a chain of elseifs. It's easier to read, and sometimes the compiler can do a better job of optimizing that way, but there's another benefit as well: it's a heck of a lot easier to debug.

When you hit that switch, you only have to step one time to end up on the right branch, instead of carefully stepping over several if statements one at a time, and possibly hitting the key too quickly and stepping past it and missing something and having to start over.

Answer 6

I prefer switch in those kind of cases, it matches much better the point of the code, execute a different statement for each different input value. The if..else acts more like a "trick" to achieve the same effect.

switch statements are also cleaner, it's easy to have a typo hidden in all those ==

Also, for big blocks in C, switch is faster.

else..if can be more appropriate when you have something like ranges (between 1 and 100, do this, between 100 and 200 do that), or in C, when you try to make switch with elements like strings (that is possible in other languages). Which is a same.

I tend to use a lot of switches when I program in C.

Answer 7

I generally don't like either approach. Long switch or if statements just beg to be refactored to an object oriented abstraction (however your example I would classify as short, not long).

I would personally wrap that kind of code into a separate helper method.

private string GetInsult()
{
    int which = (int)(Math.random() * 3);  //  Result is 0, 1, or 2.

    switch (which) {
        case 0: return "You look so much better than usual.";
        case 1: return "Your work is up to its usual standards.";
        case 2: return "You're quite competent for so little experience.";
        default: return "Oops -- something is wrong with this code.";
    }
}

public void Foo()
{
    string comment = GetInsult();
    Print(comment);
}

Placing the switch in a separate method allows you to place return statements directly inside the switch statement (at least in c#), eliminating the need for break statements either, making the code much easier to read.

And this is imho much nicer than the if/else if/else if approach.

Answer 8

Pick something that is efficient, terse, and then document not just what you've done, but why.

Code can be revisited, and not always by its original author.

There are times when you might deliberately choose one implementation over another because you're forward-thinking about code that doesn't exist.

Answer 9

In python, there is no switch statement, because if/elif/else is nice:

a = 5

if a==1:
    print "do this"
elif a == 2:
    print "do that"
elif a == 3:
    print "do the other"
elif 3 < a < 9:
    print "do more"
elif 9 <= a < 15:
    print "do nothing"
else:
    print "say sorry"

Simple right?

Answer 10

One of the things that makes the C/C# style switch particularly annoying is the insistence on the case value being literals. One nice thing about VB/VB.NET is that select/case allows each case to be any boolean expression. That is convenient. Insofar as a series of mutually exclusive boolean expressions is often helpful, a series of if/else ifs is more flexible, not to mention being more efficient to type and read.