"switch case" - bad?

Question

C++ / C#

Is there some kind of unwritten rule not to use switch case in C#?
From time to time I meet in the code a stack of ifs or ternaries nested in the place of which one could use swich case

Answer 1

I can throw you such a code that you will not only forget about the switch case, but about the syntactic sugar in general.
Do you think this code will be an indication that syntactic sugar is bad?
I think you get the gist. Somewhere it is more convenient to use if-else, somewhere switch-case. Someone simply does not like switch-case for some reason of their own.
The main thing is that this should not happen, otherwise I have already seen it somehow, and in a not very small project:

switch (*bool переменная*)
{
    case true:
        *действия*
    break;
}

Answer 2

Of course, if the switch improves the code, then you need to use it. The example with a stack of ifs is the same case. But the switch may not always be applicable.
But sometimes it happens that, although it can be made a switch, it is better to make it a condition, for example, the condition if (a>10 && a<=20) is better than taking ten cases.
PS I once made one program - a processor emulator, with the execution of user code in assembler. That processor has about a hundred instructions, and I made 100+ cases, for each instruction in the case, a method was called. In principle, it was quite convenient, I divided the cases into groups, and separated them with comments (to make it easier to search by code). But now I would do it differently - I would make a class hierarchy, and call the handler using something like this: Processor.Execute(instruction), and I wouldn't have to do a hundred cases.
(This was in 2004, written in Delphi.)

Answer 3

About the unwritten rules for writing any code, you must first check with the one who wrote this code or who supports it now. A particular developer / team may have their own unwritten rules that they personally need.
And the switch itself is used often enough not to consider it evil. Much more often than goto. Moreover, switch in sharpe is much "safer" than in the same C ++, for example, the compiler makes sure that you put break if you have code after case.
Read the code of popular libraries on codeplex or github to see everything yourself.

Answer 4

As colleagues said, switch-case is not always applicable. The main principle when switch-case is justified is 1) you have MANY (more than 3) sets of instructions depending on the value of the parameter. 2) The strict equality of the parameter and its values ​​is checked. If the logic is more complicated (non-strict equality or several different checks for different parameters) - if else should be used. And if you really delve into the bowels of OOP - there are such things as inheritance and method overloading. Those. you'll write someObject.someMethod() and the logic will be defined polymorphically, but that's another story.

Answer 5

switch is visually easier to read because the variable and what happens to it are immediately clear. Easy to change.
Plus, code generation works pretty well on things like Enum.
In if, you need to look through all the options, since there is no restriction on one variable and in general you get a bunch of brackets.
You can also make compact finite state machines (FSMs).

case "3":
case "large":
    cost += 50;
    goto case "1";

Answer 6

There is no such general unwritten rule "switch is bad"
It is believed that a large number of switches in the code is a sign of bad OOP design. You can get rid of most switches using inheritance, but this can complicate the understanding of the code, because it is easier to read a small piece of code, understand what and where, than to look for connections, which class was used.