There are several different ways that you can code a switch statement in JavaScript. Not all of these are really appropriate to use as they can lead to problems with the code in the future.
Let's look at the various ways of coding the switch statement and consider which ways should and shouldn't be used.
Example One
switch (x) {
case 'a':
doThis();
break;
case 'b':
doThat();
break;
...
This is the basic switch statement with the processing for each value completely separated. Each section of code starts with a case and ends with a break. Only one of the sections of code gets run.
Example Two
switch (x) {
case 'a':
case 'c':
case 'd':
doThis();
break;
case 'b':
doThat();
break;
...
In this second variant we have added two more cases. In this variant there are two or more case statements that follow immediately after one another. This means that the code that follows the cases through to the break statement will be run if any of those cases applies. This code is also relatively easy to follow since having the cases follow immediately after one another like that clearly shows that the following code is intended to apply for all of those cases.
Example Three
switch (x) {
case 'a':
doThis();
case 'b':
doThat();
break;
...
This version of the switch statement is where things become confusing. The way that JavaScript processes switch statements means that each case runs the code through to the break statement immediately following. With this code that means that when the value is equal to 'a' both the doThis() and doThat() functions will be run. This might be what is intended or the code in our first example above might be what is intended with the break statement for the first case having been accidentally omitted. The processing will fall through to run the all the code preceding the break statement regardless of whether that was what was intended or not. When attempting to debug errors in scripts that contain code like this (particularly if it is something written some time ago that has been recently changed) you may not be completely sure that the fallthrough is actually intentional and is not the cause of an error in the processing.
This construct should therefore be avoided when writing your switch statements. The following version achieves the same result as the fallthrough without the confusion of whether it is intended or not and so makes maintaining the code far more straightforward.
Example Four
switch (x) {
case 'a':
doThis();
doThat();
break;
case 'b':
doThat();
break;
...
With this variant of the code you no longer need to consider whether an error in your processing might be caused by a missing break statement. If you always use this variant in place of fallthroughs then you will know that where ever you do find a fallthrough in your code that it definitely does represent a missing break statement.
Example Five
switch (x) {
case 'a':
doThis();
// deliberate fallthrough
case 'b':
doThat();
break;
...
This variant uses a comment to label that the fallthrough is deliberate so that you know that the omission of the break statement is not an error. This is better than having a fallthrough without the comment as we had in example three however using self documenting code is always better than having to use comments to describe what the code does and the processing in example four is far preferable to this version.
One problem with using comments to explain what the code is doing is that the code doesn't depend on the comment for what it is doing and so the code can be changed without the comments being changed to match and you therefore cannot rely on comments necessarily being correct when you are debugging chances to the code at a later date. Using a version where the code itself makes it clear what is happening is always to be preferred.
