I've never become overly convinced that switch statements are that much cleaner than `if else if else if else if else`

That's why we never have switch in Python 😁

And, the dictionary is always a better and cleaner alternative for the ugly switch.

def my_switcher(x):
    return {
        'a': 1,
        'b': 2,
    }[x]


print(my_switcher('a'))
print(my_switcher('b'))

The main detractor with if statements is that you have to reduce your logic down to booleans, which can later be hard to trace through. But, switch statements do not go far enough to help the situation either. Reducing your logic down to integers or strings is not that much better of an abstraction. Both force you to reduce the expressiveness of your solution down to a primitive level.

This is a reason I am a big fan of Union types, which allow you to explicitly model your logically different cases along with their different related data. Combined with pattern matching, you can branch off those logical cases as-is. My favorite language which supports this is F#.

For me its about using the semantics of the language to communicate as much information as possible to other developers (and my future self). Its the same reason I prefer map, filter, reduce over for loops. By using switch instead of else if, I communicate a more specific action is taking place: dispatch over a single value. It's a small thing, but its also easy to do and makes my code a little more compact, so why not?

Switches as well as conditionals with many branches(else ifs) are generally indicative of a different issue all together.

Switches can be a good choice in the case of a clearly defined unchangeable list of things to check against, like days of the week(I pray to god there will only be seven in the future too). They are also sometimes good in the case that you actually have found a use case for the fall through effect you get when you don't use a break. Switches also are very hard to do in a way that enables defensive programming. It's easy for a switch to have 4 or 5 cases, then someone comes in and adds one, comes in and adds another, then another, until you have a giant mess of cases.

Generally, like @rossholloway94 mentioned, Enums are a much better fit. The way that @0xrumple showed in python can be done in many other languages that don't have real Enums, but is essentially an Enum as well. Alternatively, in certain use cases, something like a rule matcher and handler can be a better fit.

class Foo implements RuleHandler {
    public function canHandle(condition) : bool {
        if(condition === something) { return true; }
   }

   public function handle(thing) : Bar {
        return thing.thing() + thing.otherThing();
   }
}

Using a switch can also be indicative that whatever logic you're doing in the switch, is really something that should be on each class to implement which can be similar to the model above. Basically the Strategy design pattern.

//instead of this
function doThingsThing(thing: Thing) : void {
  switch(thing.val) {
    case 1 { thing.a + thing.b; break; }
    case 2 {thing.a * thing.b; break; }
    // more cases
    default { //this should never happen }
    // NEVER DO THIS TO A DEFAULT IF IT SHOULDN'T HAPPEN THROW AN ERROR
  }
}

//this
function doThingsThing(thing : Thing) {
  thing.doThing();
}

abstract class Thing { abstract function doThing() : Thing; }
class Thingy extends Thing { function doThing() : Thing {this.meh = 2; return this; } }
class OtherThingy extends Thing { function doThing() : Thing { this.meh = this.meh * 2; return this; } } 

The reason a switch never feels better than many else ifs is because they are basically the exact same thing. The kind of feel that gets hammered in a lot of beginner tutorials that explain switches is something like "If you have a lot of conditions, use a switch!" and also the examples show how to convert a thing with a lot of else if statements into a switch.

One more time for clarity:

• Consider using an if in the case that:
  • There are a TRULY finite number of cases
  • The fall through logic will really help(though there are OOP ways of handling this too that I didn't show)
• Some switch alternative candidates are:
  • Enums
  • Rule Handler matchers
  • Interfaces in classes

Having the fallthrough can be nice for certain cases when you want to keep your code DRY or want to avoid a ton of || operators in your if statement.

The switch operator can be much cleaner than if though, notably for small return statements. For example:

switch (x) {
  case 'a': return 1;
  case 'b': return 2;
}

is much cleaner than

if (x === 'a') {
  return 1;
} else if (x === 'b') {
  return 2;
}

Of course, it does come down to personal taste, but since languages provide the operator in the first place there's obviously a reason for it.

In terms of performance, it never practically matters. For sake of the argument, switch is much faster if you have a large number of cases and slightly slower with small number of cases. The compiler is aware of the number of cases and will convert the switch statement into a constant lookup time hash table once it exceeds a threshold. But once again, for 99.999% of code, the difference between the two will never be meaningful.

I personally think that they are used differently, and that using them both is actually the best option. If/Else can be used very broadly, but with switch it's pretty niche. It's essentially a jump table that's useful when you have a ton of outcomes given some input. When I see a switch, I immediately know the class of problem it's trying to solve. With if/else, it could be much broader.

Personally, I oppose switch statements because they force you to opt-in to break rather than breaking by default (i.e. use continue for fallthrough). I feel like every time I write a switch statement I forget a break on one of the cases. Then, I'm stuck exposing that fallthrough case during testing. In contrast, you don't really get that same ambiguity with if/else if/else.

Swift's switch is the only one that I think gets it right. It provides enough simplicity and usability to warrant use over if-else chains.

From docs.swift.org/swift-book/Language...

• compund cases case "a", "A":
• interval matching case 1..<5:
• tuples switch point: case (0, 0)
• value binding case let(x, y)
• where checks
• explicit fallthrough

Granted, each of these can still be done with if-else, I like the convenience of it all.

Considering it rapidly speeds up your conditional statements, I will always use a switch statement. A switch statement acts as though you are accessing an array via an index. Whereas an elseif statement has to process each conditional statement until it passes.

I much prefer pattern matching like in F# to switch statements. Eevee did an interesting blog on the history of the switch statement. I dislike the fallthrough behavior and find it visually displeasing in a code base.

I feel that with Java, if you have a switch statement, each condition can probably be modelled by an enumeration. And if that's the case, that can be refactored so that each enum type has a common abstract method to be called.

For me it depends on the situation really. If I have a definite limited set of values I'm looking for, I may use a switch. To me, it can be easier to read the values down a column with it. If I'm looking for boolean conditions, the if will probably be the best. But just depends.

In ruby case statements feel less verbose, less prone to error since the intention is to validate a single statement against multiple outcomes and is more human readable.

With linting case statements are one way to still have compact code.

Everything has its utility.

if    status == :active     { '/active'}
elsif status == :incomplete { '/incomplete'}
elsif status == :suspended  { '/suspended'}
end

case status
when :active     then '/active'
when :incomplete then '/incomplete'
when :suspended  then '/suspended'
end

When I'm adding some new functionality to something the main thing I'm concerned with us maintainability, and a big part of that is code readability. If statements are easier to document, at least in my opinion, and they do a better job at being representative of their purpose and the current context of the code.
Switch blocks can certainly be contextual and representative, but it takes more effort to ensure that the context and logic are properly represented. I will say, that fallthrough can be very useful in the right scenarios.

Since Java 8 I don't use switch case anymore for Java. I find it much more readable to create a functional interface, and add it to the enum. For example if you have an enum with different types of messages, and you want to correct topic for that type depending on some TopicConfiguration class. You can add a lambda config -> config.emailTopic to all the enums. Reducing it to just a single function call on the enum when needed.
In Rust there not even is enum, there is match which is more powerful. And you can use traits to get the same kind of construction as described for Java.