(where stuff, nonsense and whatever are usually a bit larger). I really don’t understand where this has come from – the if based form isn’t nearly so idiomatic for selecting between a range of values and this seems to have come from nowhere pretty much. Is there some code base out there where this is common practice or something?

Switch statements are generally more powerful than standard ‘if’ conditionals. They have readability, which makes them easier to understand, on their side. They’re easier to debug, and as a result, easier to maintain.

@Elessar- Can you provide examples of languages where switch statements cannot operate on strings? Python doesn’t have direct “switch” support, but it can be easily emulated using dictionaries, which of course, support strings. Perl uses “when”, which is quite powerful, and operates on strings. Visual Basic has “Case” statements which allow operating on strings. C++ has the STL map container. Many other languages support operating on strings, either with a direct “switch/case” function, or functionality builtin elsewhere in the language.

I’d say the both ways also differ in what is being expressed. In the one case one has multiple cases being formally on the same level. In the other case you have some decision tree to decide what is used. While sometimes such a decision tree might involve different variables and only after some modifications ending up to be only about one variable, there are also cases where the logic is about some decision tree. Even if everything is about the same variable, so a later case might never happen even if it was a switch statement, it can be more expressive to write it as the “first check this condition, otherwise check something else” that it is meant to be.

The cases you have seen might not have been from the second case, but perhaps the places they got the pattern from had.

Bernhard Rlink, actually I’m dealing with a lot of decision tree in kernel from what I witnessed there are two common practices:
using a data structure that will dynamically resolve a unique state – that paradigm actually use a macro call / function call :
value = dtree_get_end_state(&value)

so you will see a switch case for enamurators.

in cases of getting some number (result and not a state) you would witness a small if else (since switch case can’t be done here).

the second paradigm is actually coding the dtree (example when taking the exported trees from weka like systems) – this will resolve in an ugly canonical if else structure.

about the original code I witnessed this kind of practice in audio processing cards propriety code (that can be loaded for specific kernels).

@Aaron: C, the language in question. Switch in C doesn’t do the right thing on char*, for the same reason that == doesn’t; you need strcmp.

Switch also doesn’t let you write more complex conditions than “subject_of_switch == constant value”. You can’t compare to a non-constant value, you can’t add other conditions, and you can’t call arbitrary predicate functions.

Also, switch has a lot more visual noise when writing a simple condition; it only makes sense when switching between several different values.

In my opinion, the switch statements is quite difficulte to use (don’t forget break), but this statement have few benefits :
– the value tested is write once
– the code is more readable (you know that all case is the evaluation of ==)

For this lats point, when the case blocs is too long I think that the using of functions is a good idea to limit the size of switch to one screen.