🚫 Stop using SWITCH, please 🙏

Imho this article is just creating a problem out of absolute nothing.
A switch statement is totally fine to use until it reaches a distinct amount of switch cases.
After that a refactoring would be necessary to maintain readability.
This would also be the case whe using if statements.
So just clickbait?

Here the original article source:
dev.to/tauantcamargo/replace-your-...

The decision to use or avoid switch statements depends on the specific situation and the developer's preferences and coding standards.Thanks for sharing

In my personal opinion, the switch-case block in the first code block is perfectly fine and in my opinion also better than the presented alternatives. It is much more readable due to less code and probably also faster and more efficient than the other solutions.

The if-else option has to evaluate the condition three times in the worst case, instead of once. Not a big deal, to be honest, but if we are discussing such a topic, it needs to be mentioned.

The key-value option (object or map) contains much more boilerplate code, which makes it harder to read, understand, and maintain. It also causes memory overhead due to additional objects (map, functions, etc.).

That being said, I would extract the three notification functions into three separate functions and call them from either the switch block or the if block. No need for overengineering.

It certainly makes sense to avoid switch blocks in certain cases, especially if they span long lines of code. However, this is not such a case. And if the post title has such a strong opinion about switch-blocks, it should also present a strong use case against them.

If you use TypeScript, you don't need to refactor your Switch statements. You can make them safer with this trick:

type Color = 'red' | 'blue' | 'green'

export function preventSwitchDefault(_: never) {
  throw Error('this code should not be reached')
}

export function testColorSwitch(color: Color) {
  switch(color) {
    case 'red':
      return 'color is red'
    case 'blue':
      return 'color is blue'
    default:
      preventSwitchDefault(color)
  }
}

When you use type never TypeScript explicitly checks that default case is unreachable and shows you an error if it isn't.

Strongly disagree.
1) I don't think switches are less readable when you are used to them. They don't come up very often in code because they are only useful in specific cases so they might look "odd" to the inexperienced eye.
2) You haven't mentioned that switches are powerful when mutliple cases lead to the same branch.
3) Switch cases are NOT tested sequentially like a chain of if {} else if {}. Try to write a little piece of C code with a switch, compile it, look at the generated Assembly result and it might surprise you how good compilers are at optimising switches.
4) When it comes to performance, using a string as a case value is already a bad idea. A properly designed software should use enums for that anyway (in JS too). Besides, hashmaps are dynamic runtime structures, so they are not as predictable and therefore not as optimisable as the code branches of a switch, and that's true for any language.

The only thing I would agree on is that switches are often used to patch bad design, which might also be why they have a bad reputation. If I have a lot of branches in a switch, I would try to refactor the code using polymorphism.

Partially agree with you, although unsure about the proposed solution... In most cases I would just encourage people to use guard clauses, with clear descriptions like:

const isUserSigningIn = true

if(isUserSigningIn){
  // Do sign-in stuff
  return
}

// Etc...

I would take a switch statement over the provided alternatives any day. We need to keep readability in mind. When you return to that specific section in three years, you want to see at first glance what's happening.

In react I using switch-return for useReducer, I think that way much simplier, than create lot of extra function.

for example:

export const gameReducer = (state:MainState, {type, payload}):MainState => {
  switch (type) {
    case SET_HERO: return {...state, hero: payload};
    case MOD_HERO: return {...state, hero: payload(state.hero), combatResult:null};
    case NEXT_ROUND: return {...state, round: payload(state.round)};
    case SET_GAME_STATE: return {...state, game:payload};
    case SETUP_ENTITIES: return {...state, entities: payload};
    case SET_MOB_LIST: return {...state, mobList: payload};
    case MOD_ENTITI: {
      const {entities} = state;
      return entities[payload?.uid] 
        ? {...state, entities: {...entities, [payload?.uid]: payload} }
        : state;
    };
    case FOCUS_ON: return {...state, focus: payload};
    case PLAY_ACTION_ANIM: return {...state, actionAnim: payload};
    case PLAY_FLOW: return {...state, flow: payload};
    case ENCOUNTER_BEGIN: return {...state, encounterResult: null};
    case ENCOUNTER_RESULT: return {...state, encounterResult: payload};
    case SET_AUTO_FIGHT: return {...state, isAutoFight: payload};

    case LEVEL_UP_HERO: return {...state, hero: increaseLevel(1)(state.hero)}
    default: return state;
  }
};

All this hassle can be avoided just by adding a "default:" with an error throw. If you forget to add the new fruit to the switch, it will throw an error exactly the same as your object solution.

Also, if the input comes from "outside" (not fully under your control), your object solution is bugged. Use "toString" as the notification name and see. Trying to find a safer solution you just created an unsafer one. Sometimes overengineering is a problem more than a solution.

Easier to maintain: As new notifications are added, there is no need to add more instances inside a switch statement, just add a new function to the notificationDirectory object.

What? How is one of these things easier than the other?

they kinda seem harder to read

Agree with the article unless you can guarantee a finite number of cases over time.

In almost all other cases a map keyed to your execution function is more readable, scalable, testable and importantly most people forget, much more commit friendly. I've had plenty of collisions on active teams with switch statements that never happened (or are much simpler to resolve) when simply populating a map.

Apologies for the previous use of the word "switch." I'll avoid using that term moving forward. If you have any specific requests of Facebook owner game or questions, please let me know, and I'll be happy to assist you.

Yeah sometimes it would be nicer to extract an object with the operations. But one of the problems that I have faced is that you no longer can use a closure to access the data where the original switch was. I can't think of a way to achieve the same result when the switch was inside a class, accessing private members to carry out the result.

Congratulations you just replaced performant code for code that YOU subjectively think looks better with a GC overhead. Sure you can do it but none of the so called benefits hold true.

You may think that a hash map is O(1) but it's not it comes with a huge overhead even if you ignore the fact that you just created VM functions.

Unless your use case involves hundreds of return paths linear search will ALWAYS be faster. In both cases you can optimize based on code execution rank but switch case may or may not be optimized for by JIT depending on implemention.

So please stop posting about micro-optimizations.