If (all) else is complicated, switch to switch?

Switches have the potential to be super powerful, the ability to let conditions fall through...

switch(state) {
    case 'foo':
        console.log('one');
    case 'bar':
        console.log('two');
        break;
    default:
        console.log('three');
}

// When state === 'foo', 'one' and 'two' are logged

...means there are some complex logical flows that could achieved.

But the hidden complexity fall-through case statements add and the ease of missing them means it's far more likely you'll introduce hard to find bugs or regressions.

As a result, most coding styles either warn or actively disallow case statements without a break; statement at the end. Removing that ability removes the key differentiator of a switch statement and makes it a slightly more concise if..else if statement assuming you have a set of conditions checking the same variable for different values. Pretty niche!

I think it's worth using. In fact, in the previous enterprise-level project I worked on, 'switch'es were the most prevalent for handling several conditions. If/else's were seldom used.

Sounds like Ramda cond. Thinking about a switch statement in terms of functions might be an interesting new perspective! This stack overflow piece might help.

switch in c# is more clear. I didn't use in javascript

Too many switches is bad design. You may want to switch to proper object oriented principles and this avoid so many ifs.

It doesn’t bring any value and is more complicated: breaks, their absence, etc. It feels hacky because it is. It’s a bad thing to be hacky when it’s not needed.

can use objects like below, looks very clean

function calculate(operation) {
  const map = {
    add: handleAdd(),
    subtract: handleSubtract(),
    multiply: handleMultiply(),
    divide: handleDivide()
  }

  return map[operation]
} 

const handleAdd = () => {
  // do something magical
}

calculate('add')

Little OT here. I think switches are great for revealing unexpected program flows in a multi branch szenario, which is why the exact match condition is so important.

You want your program being as deterministic as possible and therefore throw exceptions when the program deviates at any point. Switches are a nice way to do that:

f = value => {
  case 'foo':
    return stateA()
  case 'bar':
    return stateB()
  default:
    throw new Error(`No state for ${value}`)
}

Relying on truthy/falsy for branching is a great feature of Js but can also lead to false positives / false negatives (think empty Strings, Number 0) that require much more tests than being explicit in the first place.

TBH I've never considered doing this but now that I see it, it feels like an abuse of the switch statement.

Neither example seems particularly "clean" to me.

My preference would be to refactor this code such that you can return early.

function getLogMessage() {
    if (someExpressionA) {
        return 'yes';
    }

    if (someExpressionB && someExpressionC || someExpressionD) {
        return 'nope';
    }

    return 'maybe';
}

console.log(getLogMessage())

Much more straightforward than either IMHO.

I think it depends.

If it looks cleaner to you and your team, then that's the answer (use it).

Personally, I have a slight preference to normal if / else statements because:

• in JavaScript (the language I use at work), the switch statement wouldn't work unless each expression was explicitly true or false. Whereas if / else statements also work with "truthy" or "falsy" values. For example if ('hello' && 'goodbye') passes, because non-empty strings are truthy, but switch(true) { case 'hello' && 'goodbye': } wouldn't pass.
• I'm not used to using switch statements like that, so they might catch me out until I get used to them (and others too). If they were the standard convention, then it wouldn't be a problem. As they say, convention over perfection, although this is a very small change in this case.
• More realistically, I don't encounter long conditionals often. Short conditionals don't seem like a great use case for switch statements. For example:

if (!condition) {
  return foo();
}
return bar();

In summary. It's not my cup of tea. But it's not a big change, so I would do it if that's what the team preferred. If you and your team like it, then by all means use it :).

Coincidentally, a friend of mine told me this week his switch(true) did not pass his code review, despite the arguments of it looking much clearer. Some people will not accept this, so beware 😛

It's pretty straight forward. But I never thought of it 😂 good tiny trick!