JavaScript: Is Fallthrough From Switch Statement A Troublemaker?

*Cross-posting from my Medium.
Medium: Arisa F

Hi there, it’s Arisa from Japan work and living in Germany as a Full-Stack Developer.

I started my career from Frontend area.
A must programming language everyone should learn in Frontend area is JavaScript.

I teach in an online programming school, CodeGrit and sometimes, my students open my eyes with very interesting questions or discussions.

One of the most recent interesting discussion brought up by my students was about a fall-through from the switch statement.

I personally avoid to use fallthrough from switch statement but from his point of view and others was interesting and made me want to discuss the pros and cons and more.

Let’s get started to discuss.

Is Fallthrough Allowed To Use?

A short answer is YES.

It’s even used in some cases in documents like MDN as well.
Also, we don’t find a sentence written not allowed to use anywhere.

You’re free to use in the right way!

Then why some people like me try not to use fallthrough in the switch statement?
There are some reasons you must know to use fallthrough right.
It means you use fallthrough with your own risks.

This sounds a bit over exaggerated… for some of them.
It’s totally up to you whether you do mind a risk or not.
Also, it’s totally fine to use when you follow the syntax and on an efficient occasion.

Then why some people are extra being careful?

Here’s another discussion.

Is Fallthrough A Dangerous Guy?

I would say, fallthrough is a very nice guy but at the same time, he’s also a dangerous guy to hang out for some occasions.

Fallthrough is nice in situations like this.

• Many cases like over 10 of them not requiring breaks to fall through
• Many cases and very simple outputs to return

Seeing a real example is easier to understand.
Let’s take a look at this example.

Let’s imagine we’re registering Star Wars characters in some events.
They came over to your desk to register for joining an event.

Somehow, you realize there’s a lot of Jedi came over to attend your event.
It’s very annoying if you need to fill out “Jedi” for 7 times when you see 7 of them making a line towards your desk are obviously all Jedis.

Also, your colleagues understand when you make all these 7 people putting in one circle together and write once “Jedi” to describe them.
Fallthrough can do the same thing.
For this case, fallthrough is really efficient and very useful.

You would never wonder he has another side being a dangerous guy when it comes into some situations to hang out.

Let’s face the reality about who really your friend is.

When Fallthrough Is Not Efficient To Use?

You saw fallthrough worked out very well in an example from above.
But here is the example fallthrough turns out being a bad guy.

I found an interesting explanation from W3schools about that.

Sometimes you will want different cases to use the same code, or fall-through to a common default.
Note that in this example, the cases share the same code block, and that the default case does not have to be the last case in a switch block (however, if default is NOT the last case in the switch block, remember to end it with a break).
https://www.w3schools.com/jsref/jsref_switch.asp

A quick summary in here says, “if default comes in a middle of the switch block, break default as well.”

Let’s see in a source code what it means.

Based on W3school’s example, here is what we DIDN’T listen to what it was said in above.
A very simple sample to push a message out depends on a date you are in.
The selected message will be out by clicking the button linked with a click event.
I put default in the middle of the switch block and didn’t break on purpose.

Here is the result.
FYI, imagine you clicked the button between Monday to Wednesday and except Thursday to Sunday.
A result in below shows case 2, means it’s the output on Tuesday.

Then we should expect the message, “Give my Weekend back 😩.”
That’s why we put case 1 to 3 and default with fallthrough.

What the … fu… fallthrough!

We got “Almost Weekend…!! 😎” for Thursday and Friday.
The weekend is way far ahead from Tuesday, why this happens?

Here is the thing, fallthrough behaving not nice to you this time.
You know fallthrough is not requiring break unless at the end of the chunk of cases which return the same output.

You could think, “but I put default this time at the end of the chunk of cases returning the same result… maybe, don’t need a break like as I always write default in the end.”

That’s the moment fallthrough behave differently.
Also, it’s complicated because of using fallthrough.
Fallthrough lets case 1 to 3 including default all the way to the case 4 and 5 because there is no break although there is a default.

That’s the reason why I said above, “fallthrough is good for many cases and very simple outputs to return.”

We can’t deny the potential risks from fallthrough as long as we use it.
For some cases, fallthrough helps to make code look clean and tidy when it’s simple structures.
But mostly, it’s better to avoid using something when you know there could be risks.

When it comes with the project with a team, or you know your clients will ask you to maintain frequently, you don’t want to face the risks you have put in the past.

If I say more in-depth, even the switch statement is not a smart way for some people’s opinion.

“Then how do we deal with many cases when we better not to handle with if statement…?”

There is always a solution.
Here is one of them.

An Alternative Solution for Fallthrough: Use Objects

Can objects be an alternative solution to avoid fallthrough trap?
YES, and it looks very neat.

You don’t need to worry about forgetting to break cases.
No more weird results from fallthrough.

The only thing annoys you could be writing the same value for some object properties.
You realized this is based on a first example with Star Wars characters.
In many cases, people use fallthrough to make code short and clean.
But which examples are clean and short?

Absolutely, the one using objects.

This is why people like me prefer not using fallthrough.
But I’m not completely anti fallthrough.
As long as it’s fine to use in the right situation and avoiding the risks to return wrong results, fallthrough is also right to use.

Programming languages are not perfect.
Always under the development to make better and more efficient.
This is why it’s important and interesting to discuss what feels better and what was more efficient from all developers.

We are the one making programming languages better from our coding experience.

Maybe, fallthrough will be more efficient or new methods or statement will come up in the future.

Hope you enjoyed reading my entry.

Tschüß.