DEV Community

Why switch is better than if-else

edA‑qa mort‑ora‑y on June 29, 2019

In Ben’s post, he questions whether switch statements are cleaner than if-else chains. I contend they are, because they better express the semantic...

Read full post

Meghan (she/her) • Jun 29 '19

I didnt get to point out but I'm glad you did in your article that the best way to format a switch statement is indented.

switch (x) {
  case 0: {
    func();
  }
  case 1: {
    func2();
  }
  ..
}

Fernando B 🚀 • Jun 29 '19 • Edited

Great read. I particularly don't use switch too often unless I use more than 3 or 4 ifs to make code cleaner. To make switch statements even cleaner combine them with enums if your language supports them.

Switch in kotlin are nice:

when {
    x.isOdd() -> print("x is odd")
    x.isEven() -> print("x is even")
    else -> print("x is funny")
}

Cubicle Buddha • Jun 29 '19

I know you and I already discussed this, but for the benefit of your readers: in TypeScript you can still get the benefit of exhaustiveness checking even with if statements. I describe how to do that here: dev.to/cubiclebuddha/is-defensive-...

Thank you for this article though because even though I’m not a fan of switch statements (for purely subjective reasons + the break issue that you mentioned), it’s really nice to hear from the opposite perspective. Also, you made a great point about hiding complexity with your expr example. Nice work. :)

edA‑qa mort‑ora‑y • Jun 29 '19

Defensive programming is a must. It's great if you can ensure coverage even with if-else in TypeScript.

jdtjenkins • Jun 29 '19

Only evaluating the expression once, not having to use a temp variable. That's a big seller to me, that feels much neater. Great article!

Ben Halpern • Jun 29 '19

Fabulous post

Prahlad Yeri • Jun 29 '19

Another problem with switch is that you have to remember to provide the default: case otherwise you aren't covering all the cases! Its the same thing that happens when you forget the else block as shown in your if-else example. Its possible to leave out the default case in either scenario.

The break is another annoying thing and not just C/C++, even in Java and C#, you need to provide the break but I don't remember since its a long while since I've coded in those languages.

Python lacks a switch statement but I've never felt the need for it frankly. Ultimately, its just a more fancy variety of if statement!

edA‑qa mort‑ora‑y • Jun 29 '19

C++ compilers will tell you when you've forgotten a default block. I didn't remember C# needing it, since it can't fall through to the next block.

Johannes Vollmer • Jul 5 '19

Well, if you try to use a c-style switch statement that's definitely a problem. That's why I suggest you to look into the Rust way of switch: matching. It has all the good parts of switch but not the bad ones.

jmc • Jun 29 '19 • Edited

A switch indicates that you are mapping from an input value to a piece of code.

IMO when there's fallthrough, you're not mapping from values to code, but rather values to an offset in code. Like a jump table. I mention it not because I consider it to be all that dangerous but because in those languages it waters down the idea of switch-as-map.

But I agree on the whole. Often pattern matching is what you want (or the repeated application of a predicate, a la condp), and switch isn't always a perfect fit, but where it works it tends to be more explicit than the alternative.

Riccardo Bernardini • Jun 30 '19 • Edited

In Ada the corresponding of switch is case. As with many compiled languages, case is limited to discrete type (enumerations or integers). What I like of the Ada case is the absence of C fall-through (potential source of bugs) and the obligation of handling all the cases, possibly with a default branch, that is usually discouraged because it will not catch the error when you add a new enumeration value and forgot to handle it.

One could observe that it is easy to handle all the cases without default when you work with enumerations, but what about integers? Well, you can always define a subtype

  subtype Weekday is integer range 1..7;

  Tomorrow : Weekday;

  case Tomorrow is 
    when 1 => 
    ...
    when 7 =>
  end case;

Finally, if you try to use non-disjoint branches Ada Lovelace herself comes to you and slap your face with the INTERCAL manual. :-)

Oh, BTW, in the latest version of Ada you have also the "operator" version, very convenient and 40 dB more readable than usual "?:"

Name := (case Tomorrow is 
           when 1 => "Monday",
           when 2 => "Tuesday", 
           ...
           when 7 => "Sunday");

edA‑qa mort‑ora‑y • Jun 29 '19

In C/C++ they have fall-through, but more modern implementations don't have that. I believe you can even enable warnings in some C++ compilers to disallow fall-through.

Gerard Klijs • Jun 30 '19

Would it not be even cleaner to first get an enum from the expression (if it wasn't an enum already). And then call a function on the enum. It least I find it a lot easier to read, and anything specific to the enum is all together, instead of spread around.

Vlastimil Pospichal • Jun 29 '19

I got rid of all "else" in my programs. They are shorter, faster and clearer now. I used a switch, ternary, or return by context.

Kyle Titus • Jun 29 '19

Java has default. Which at least means that you know it fell through