✔||🤢 Commit or Vomit | Switch(true)

In my recent post I questioned the use of a switch instead of an if else statement. This gave me the idea of an recurring item for dev.to: Commit or Vomit! Would you commit this code or not.

It's going to be code snippets that are going to be evaluated here. Not posts because I don't want people to feel/be judged by this, only code!

So this first ✔||🤢 is from the post that started it all.

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

🐤🥇 Jasper de Jager ・ Apr 1 '21

#webdev #programming #javascript #discuss

switch(true){
    case userMissedAppointment:
        return 'nope';
    case userHasAngularExperience:
    case userHasReactExperience:
    case userHasVueExperience && userCanStartInstantly:
        return 'hire';
    default:
        return 'maybe'
}

This is just an example but the question is about the switch(true). What do you think? ✔||🤢

❤: Commit
🏷: Vomit (we all know unicorns don't vomit)
🦄: Like your post please continue this series!

Looking forward to your reactions! 😎

Comments

[Jack]

Since you're returning on each case I wouldn't even bother with elses...

if (useMissedAppointment) {
  return 'nope
}
if (userHasAngularExperience || useHasReactExperience || (userHasVieExperience && userCanStartImmediately)) {
  return 'hire'
}
return 'maybe'

Of course I'd also extract that second conditon into another method, but that's another matter.

[Natalia Asteria]

Um, making it a bit inline is better imo.

if (userMissedAppointment) return 'nope';

if (userHasAngularExperience || useHasReactExperience || 
(userHasVieExperience && userCanStartImmediately)) return 'hire';

return 'maybe';

The first line for the second if statement is too long imo. Turned it into two lines.

[🐤🥇 Jasper de Jager]

My preference:

if (userMissedAppointment) return 'nope';

if (
  userHasAngularExperience 
  || useHasReactExperience 
  || (userHasVueExperience && userCanStartImmediately)
) return 'hire';

return 'maybe';

[Natalia Asteria]

Oh yeah, I didn't thought that.

[Jack]

Personally I prefer all-or-nothing for braces, I really don't like mixing styles. If any of my code has braces, I'd prefer all of my code to have braces. But this is totally off topic and probably a topic for another C/V poll!

[🐤🥇 Jasper de Jager]

I'll save it for another ✔️||🤢 good idea.
Just have to come up with a good example 😊 and not posting a new one every day is hard but I think this is going to be a weekly recurring item from now on 😎

[edave64]

I personally like to drop the braces IF the condition is small and the statement ends control flow and logically can't have anything after, like return, throw, continue, break, etc.

[Siddharth]

This could easily have been an if/elseif/else.

You could have done:

if(someExpressionA) console.log('yes')
else if ((someExpressionB 
    && someExpressionC) || someExpressionD) console.log('nope');
else console.log('maybe');

[Bas van Baalen]

I'm not sure it's because of the editor, but I would suggest to use more lines for more readability and easier comprehension.

if(someExpressionA) 
  console.log('yes')
else if ((someExpressionB && someExpressionC) || someExpressionD) 
  console.log('nope');
else 
  console.log('maybe');

For me this already reduces the cognitive load a lot quickly see what can happen.

[🐤🥇 Jasper de Jager]

Good point for a next Commit or Vomit! What do you think about switch(true) in general?

[Siddharth]

Actually I typed my comment on mobile, so I didn't format it

[🐤🥇 Jasper de Jager]

true, this is a short example. Apart from this example would you never commit a switch(true)?

[Siddharth]

Nope 🤢

[🐤🥇 Jasper de Jager]

good to mention: the example was updated after this reply

[Milebroke]

I think the cleanest and most expressive is still this

const hasFrontendFrameworkExperience = userHasAngularExperience || userHasReactExperience || userHasVueExperience;

if(userMissedAppointment){
    return 'nope';
} else if(hasFrontendFrameworkExperience && userCanStartInstantly){
    return 'hire';
}
return 'maybe';

[🐤🥇 Jasper de Jager]

Your function behaves slightly different than the example, bit this just might prove your point of the switch not being readable enough 😅

The difference is that in the switch an angular experienced used doesn't have to start immediately.

[Milebroke]

You are definitely right :D Well in that case I wouldn't mind the right if else combo either

[Keith Charles]

While the code is valid, I think the real issue here is just the amount of conditions you're trying to parse through. Using switch (true) feels more like a band-aid than a solution I would accept say in a PR.

I'm a fan for using switches when we're actually comparing the value in switch(value). Someone mentioned checking for a match in the zodiac. Perfect use case for a switch statement.

When you have to resort to a hacky solution, chances are the problem lies more with the code leading up to this decision than the decision itself.

[🐤🥇 Jasper de Jager]

Totally agree! It's a code smell.

[Aleksandr Hovhannisyan]

Why the need for the case statement?

if (userMissedAppointment) {
  return 'nope';
}
const userMeetsTechRequirements = userHasAngularExperience || userHasReactExperience || userHasVueExperience;
if (userMeetsTechRequirements && userCanStartInstantly) {
   return 'hire';
}
return 'maybe'

Also, imo, there's no need to repeat "user" in these flags. You could just say canStartInstantly, for example. There's no ambiguity regarding who this refers to.

[🐤🥇 Jasper de Jager]

Totally agree, but would you merge it if it was in a PR for instance?

[Aleksandr Hovhannisyan]

Nope, I'd request changes here.

[Siddharth]

I can't believe some people put hearts

[Cooper Riehl]

I liked this post, not because I think switch (true) is a good paradigm (it isn't), but because the post itself is interesting.

The author isn't saying "you should use switch (true) in your code", they're saying "let's have a discussion about whether switch (true) is acceptable". IMO, that's a useful discussion!

[🐤🥇 Jasper de Jager]

That's the fun of this item 😊
It shows it's important to keep an open mind!

[Julian]

I think this is a misuse of the switch statement and its purpose.

If there is a need for this kind of hackery witchery I believe there are other design flaws which makes this code "necessary" and should be refactored to make this kind of code avoidable.

When an if statement gets so complex that you start to search for more readable ways of writing it there will most likely also be alternative ways to take it apart into smaller parts and make it more comprehensible (and maintainable) that way.

[Andrei Dascalu]

Vomit.
Either a verbose aggregation of desired Boolean checks OR return from currying some composable functions that return a similar aggregation.
I am slightly partial to the second as I believe anyone looking for FP would be.

[Antonio Radovcic]

I'd say probably vomit, but I'm sure there are cases where this way is just easier to read than if/else/return early/etc. Hard to say with placeholder-var-names.

[🐤🥇 Jasper de Jager]

Yes I agree, something to take into account for the next one in the series!
Thanks for the feedback 😊

[Antonio Radovcic]

switch(true){
case userDoesntHaveWorkPermit:
console.log('nope');
break;
case userHasReactExperience:
console.log('Hire!');
break;
case userHasVueExperience
&& userCanStartInstantly:
console.log("Hire, if they can start instantly");
break;
default:
console.log('maybe');
}

[🐤🥇 Jasper de Jager]

More of an Angular fan myself so userHasAngularExperience is going to be added 😎 but much better example, thnx!

[🐤🥇 Jasper de Jager]

Snippet was updated!

[disgusting-dev]

How about that (pre-enterprise example :))

//allocate in one place binding of all rules with results
const conditionsEnum = {
  nope: ignoringConditions,
  hire: hiringConditions,
  maybe: mbConditions,
}

let result = '';

//find first truth in there
for (let field in conditionsEnum) {
  if (conditionsEnum[field].some(condition => !!condition())) {
    result = field;

    return result;
  }
}

values in object are just arrays of functions:

const ignoringConditions = [
  () => false,
  () => false,
  () => false,
]

const hiringConditions = [
  () => true,
  () => false,
  () => false,
]

const mbConditions = [
  () => false,
  () => false,
  () => false,
]

Hope my nickname speaks for itself

[🐤🥇 Jasper de Jager]

Hope my nickname speaks for itself

🤣🤣