DEV Community

Cover image for Switch is ok
Pragmatic Maciej
Pragmatic Maciej

Posted on

Switch is ok

Switch statement had lately some bad fame, some developers avoid it as possible, and others advocate to deprecate it. Almost as if it would be some anti-pattern to use it. To make you an example of the attitude, here are few articles:

This article will try to fight with common statements against switch. So here they go!

Switch is old and clunky

Yes Switch statement is old, if statement also is old, for loop is old too, but so what? Really what a strange argument it is. New and shiny doesn't mean better.

We're forced to manually add break

That's a kinda interesting take, as in all examples criticizing switch, the switch is shown with a break keyword. It is so by purpose, to make the counterexample looking better. So no, we don't need to use break, we can use switch with return only.

switch (x) {
  case "DC":
    return "Batman";
  case "Marvel":
    return "Wolverine";
  default:
    return "Spiderman"
}
Enter fullscreen mode Exit fullscreen mode

Where is the break now?

Its not an expression

Yes, it's not. But wrapping it in a function will give us expression:

function hero(x) {
  switch (x) {
    case "DC":
      return "Batman";
    case "Marvel":
      return "Wolverine";
    default:
      return "Spiderman"
  }
}
const myHero = hero("DC");
Enter fullscreen mode Exit fullscreen mode

It is emphasizing impure and procedural programming

You work with multi-paradigm language, where you can mutate everything, you can make any side effect whenever you want, and still make such argument? Purity in such language like JS is a coding practice only. If you want to write pure code, switch will not be any blocker, believe me.

It is error prone and likely to make some mistake

Really stop using Notepad. Please.

And update your Windows 8.

Use object literals instead of switch

Yes you can, I will not say that using literal is a bad idea. But saying that switch is much worse, is still overstatement. Consider both examples:

// switch
function hero(x) {
  switch (x) {
    case "DC":
      return "Batman";
    case "Marvel":
      return "Wolverine";
    default:
      return "Spiderman"
  }
}
// literal
function hero(x = "default") {
  const herosMap = {
    "DC": "Batman",
    "Marvel" : "Wolverine",
    "default": "Spiderman"
  }
  return herosMap[x];
}
Enter fullscreen mode Exit fullscreen mode

Yes yes, I see how you look at the second, it is smaller, and there is this nice trick with default value, what a sexy thing. But, sexy should be your girlfriend/boyfriend, and not exactly your code. Smaller doesn't mean better 😂, when you look at both for sure you need a little more time for the second. Admit it!

These examples are isomorphic, there is no winner here. I don't see any issue in using one or another.

Switch statements are bad in OOP code

Yes, probably better will be your StrategyFactoryProducerPattern. But to be serious, there can be issues with OOP principles about polymorphism and switch. However do you write OOP code? If not those arguments are not a thing.

We can make some FP wrapper to never look at switch again

Why to use switch if you can function? Below example from the Eliminate the switch statement for better code article. You can make such:

const switchcase = cases => defaultCase => key =>
  cases.hasOwnProperty(key) ? cases[key] : defaultCase

const counter = (state = 0, action) =>
  switchcaseF({
    'INCREMENT': () => state + 1,
    'DECREMENT': () => state -1
  })(state)(action.type)
Enter fullscreen mode Exit fullscreen mode

than simple

const counter = (state = 0, action) => {
  switch (action.type) {
    case 'INCREMENT':
      return state + 1
    case 'DECREMENT':
      return state - 1
    default:
      return state
  }
}
Enter fullscreen mode Exit fullscreen mode

Yes but first has no {, no explicit return and there is some partial application, notice how sexy this function is called twice at the end (state)(action.type). If this argument works for you, go sleep and read this code again, and I've already said who should be sexy 😉

Switch statement is ok

There is nothing wrong with switch statement, we can use it without the break keyword, it's very explicit and clean to see all possible branches inside the switch. If you think it's not functional programming if we use switch, then look at pure functional languages which have pattern matching. Take a look at below Elm code example:

hero x = case x of
  DC -> "Batman"
  Marvel -> "Wolverine"
  _ -> "Spiderman"
Enter fullscreen mode Exit fullscreen mode

Yes, it is functional programming, and yes case of is expression, but it doesn't mean you should deprecate switch, use it, make it return in every case. Don't complicate things which should be simple.

Thank you.

Photo by Nick Nice on Unsplash

Top comments (17)

Collapse
 
josemunoz profile image
José Muñoz

I am in the bandwagon of object literals over switches, I know it doesn't have a tremendous impact but combining it with some ES8 features like optional chaining and nil colascing makes it even better IMO:

const counter = (initialState = 0) => (action) => {
  const nextState = {
    'INCREMENT': () => initialState + 1,
    'DECREMENT': () => initialState -1
  }[action.type]?.() ?? initialState

return nextState
}
Enter fullscreen mode Exit fullscreen mode
Collapse
 
macsikora profile image
Pragmatic Maciej

It goes to the point that switch is not expression. Don't get we wrong optional chaining and nulish colascing are great feature, but I don't believe using them as you have shown is a good example. It's just not needed here.

Collapse
 
josemunoz profile image
José Muñoz

Hahaha I agree completely, specially nil colascing which would easily be replaced with a logical or instead, it’s just a personal preference

Collapse
 
vonheikemen profile image
Heiker

The best thing about switch statements is that you're not limited to strings.

function fun(data) {
  switch(data.constructor) {
    case Symbol:
      return 'You gave me a symbol';
    case String:
      return 'No strings attached';
    case Array:
      return 'To map or not to map';
    case Number:
      return 'something something 42';
    case Boolean:
      return 'is it true?';
    case Promise:
      return 'maybe, maybe not';
    case Function:
      return "Don't call us, we'll call you";
    case (async () => {}).constructor:
      return 'Ooh, fancy stuff';
    default:
      return 'what?'
  }
}

const some_fun = function() {};
const async_fun = async function() {};

fun(['hello']);
fun(74);
fun('this');
fun(Symbol('What?'));
fun(true);
fun(some_fun);
fun(async_fun);
Enter fullscreen mode Exit fullscreen mode
Collapse
 
macsikora profile image
Pragmatic Maciej

Nice. Thanks for sharing

Collapse
 
jonrandy profile image
Jon Randy 🎖️ • Edited

Your example with the object literal is overly long:

const hero = (x = "default") => ({
    "DC": "Batman",
    "Marvel" : "Wolverine",
    "default": "Spiderman"
}[x])
Enter fullscreen mode Exit fullscreen mode
Collapse
 
macsikora profile image
Pragmatic Maciej

I have waited for that 😉

Collapse
 
bytebodger profile image
Adam Nathaniel Davis

I've been in both camps before. I think I went at least 10 years without writing a switch/case anywhere. But in the last several years, I've actually come back to switch statements. It's not like I use them everywhere - or even, often. But I do use them. IMHO, the "proper" use-case for switches is whenever you are checking one variable against a set of known values. I do not like any use of a switch where people are trying to embed logic that goes beyond the basic idea of a switch.

Also, although I'm, admittedly, a Certified Redux Hater, it's hard for anyone to love Redux and hate switches. I've even seen Redux fanboys grumble about switches that are written outside of their reducers - but they're perfectly fine using a ton of switches inside their reducers. Such pedantic distinctions make little sense.

Railing against the use of switch makes no more sense than railing against a while loop. Are while loops usually the "right" choice?? No. But there are absolutely times when a while loop is the right choice.

Collapse
 
nosknut profile image
nosknut

Can we all just gather around the campfire and agree that redux is an unmatched headache? 😂 People dump implementation logic of 50 lines in their reducers and the code becomes impossible to follow in large projects.

Collapse
 
torstendittmann profile image
Torsten Dittmann

My favourite Javascript switch feature is the ability to use switch(true) followed by cases with with comparison operations.

Looks much cleaner compared to a lot of if/else.

Collapse
 
siy profile image
Sergiy Yevtushenko • Edited

New and shiny doesn't mean better.

Smaller doesn't mean better 😂, when you look at both for sure you need a little more time for the second.

I'm constantly telling those phrases to Kotlin fans :)

Collapse
 
danomatic profile image
Dan Blaisdell • Edited
const counter = (state = 0, action) => {
  switch (action.type) {
    case 'INCREMENT':
      return state + 1
    case 'DECREMENT':
      return state - 1
    default:
      return state
  }
}
Enter fullscreen mode Exit fullscreen mode

can just be

const increment = (number = 0) => {
  return number + 1
}
const decrement = (number = 0) => {
  return number - 1
}
Enter fullscreen mode Exit fullscreen mode

unless you need it to be so dynamic (uses user input or is an event handler that lacks types) that your code doesn't know which action to take without user input. if you end up writing:

counter(5, 'increment')
Enter fullscreen mode Exit fullscreen mode

...you are just converting function names into string names and making your code breaky and complicated and too clever for its own good

Collapse
 
Sloan, the sloth mascot
Comment deleted
Collapse
 
nosknut profile image
nosknut

Depends on how extreme it is. If i have to spend an extra 10 seconds reading your code to understand something that a switch could tell me in 2 lines, and i have to do that every time i read your code 20 times a day for a year, we are having a meeting 😂 Otherwise, people can do whatever they want for all i care.

Collapse
 
ryands17 profile image
Ryan Dsouza

+1, although I would love for pattern matching to land in JavaScript as it's the best of both worlds :)

Collapse
 
macsikora profile image
Pragmatic Maciej

Yes you are right, I have wrongly made a title of this paragraph. Changed already

Collapse
 
ifarmgolems profile image
Patrik Jajcay

Lodash _.cond with lodash/fp version for the win!