Why is there never any controversy regarding the switch statement? [closed]

Question

We all know that the gotostatement should only be used on very rare occasions if at all. It has been discouraged to use the goto statement countless places countless times. But why it there never anything like that about the switch statement? I can understand the position that the switch statement should always be avoided since anything with switch can always be expressed by if...else... which is also more readable and the syntax of the switch statement if difficult to remember. Do you agree? What are the arguments in favor of keeping the 'switch` statement? It can also be difficult to use if what you're testing changes from say an integer to an object, then C++ or Java won't be able to perform the switch and neither C can perform switch on something like a struct or a union. And the technique of fall-through is so very rarely used that I wonder why it was never presented any regret of having switch at all? The only place I know where it is best practice is GUI code and even that switch is probably better coded in a more object-oriented way.

Answer 1

Switch statements are occasionally much more readable than cascading sets of if else blocks. In the case of enums, switch statements, unlike if blocks can be easily checked to ensure that all cases are covered. They are also likely to be more efficient. Although sometimes code would be more readily expressed in an OO style than using switch, other times switch is the right choice. This is because enumerated data types and switch statements are mathematically dual to inheritance hierarchies and dynamic dispatch. While it is easy to add new operations with new switch statments, it is hard to add new cases (since each operation must be modified). While, with OOP it is easy to add new cases, it is hard to add new operations. This is called the expression problem.

Fall through is occasionally useful, for example it lets you implement duffs device. But, I think that most people agree fall-through by default is a mistake. Language like Go use an explicit fallthrough statement and break by default.

Languages with Algebraic Data Types like Haskell and ML show that a more general form of the switch (in this case it is an expression) is a very elegant code structuring tool well suited for a large variety of problems. switch in C and C like languages is just a little buggy and limited, but honestly, if you are forgetting the syntax of a core feature of the language you use everyday something is wrong.

Answer 2

Perhaps I'm misinterpreting this question, but there is nothing wrong with a switch statement. There are cases where you simply want to operate on a particular value, and a switch statement is perfectly clear syntax. An if/else statement is, of course, more logical in the strictest if/else sense.

A visual example helps; which of these looks better?

Traditional switch statement:

switch (a) {   
    case 1:
        print "a equals 1";
        break;
    case 2:
        print "a equals 2";
        break;
    case 3:
        print "a equals 3";
        break;
    default:
        print "a does not equal any of 1-3";
        break;
}

Total lines: 14

Compacted if/else statement:

if (a == 1) {
    print "a equals 1";
} else if (a == 2) {
    print "a equals 2";
} else if (a == 3) {
    print "a equals 3";
} else {
    print "a does not equal any of 1-3";
}

Total lines: 9

Expanded if/else statement:

if (a == 1) 
{
    print "a equals 1";
} 
else if (a == 2) 
{
    print "a equals 2";
} 
else if (a == 3) 
{
    print "a equals 3";
} 
else 
{
    print "a does not equal any of 1-3";
}

Total lines: 16

The compacted if/else statement is technically the shortest in terms of lines of code, but looks the most cluttered. There are exceptions to this, of course, as many languages support the case for one line statements in an if/else (or many don't use parentheses/braces in such statements at all), but the general idea gets across that switches do have their place and are not inelegant if operating on one variable.

Edit: I see that some of this was referenced in Robert Harvey's comment.