Maintainable JavaScript — Switch

Creating maintainable JavaScript code is important if want to keep using the code.

In this article, we’ll look at the basics of creating maintainable JavaScript code by writing switch statements.

The switch Statement

switch statements are useful for doing something after checking for some value.

There are better ways to format swicth statements.

JavaScript switch statements behave differently than other languages.

Any type of value may be used with it.

And any expressions can be used with a valid case .

Other languages require the use of primitive values and constants respectively.

Switch Indentation

Switch statement’s content should be indented.

For instance, we write:

switch (condition) {
  case 1:
    // ...
    break;

  case 2:
    // ...
    break;

  case 3:
    // ...
    break;

  default:
    // ...
}

We indented the case statement and the content inside it.

The indentation is done with 2 spaces.

This makes the content easier to read.

We also have ab extra line before and after each case statement from the second one on.

Doug Crockford’s style guide has another suggestion.

The line between the case statements is removed.

For instance, we can write:

switch (condition) {
  case 1:
    // ...
    break;
  case 2:
    // ...
    break;
  case 3:
    // ...
    break;
  default:
    // ...
}

We remove the blank lines in between the parts of the switch statement.

However, all style guides have the same recommendation for indentation.

Falling Through

Accidentally omitting the break keyword at the end is a common mistake we make when we write switch statements.

This will cause the case statements below them to also run.

Some people suggest that every case should end with break , return or throw without exception.

This way, the case will end where we expect them to end.

If we make it clear in the code that falling through isn’t a mistake, then we can let the case statements fall through.

For example, we can write:

switch (condition) {

  // falls through
  case 1:
  case 2:
    // ...
    break;

  case 3:
    //...
    // falls through
  default:
    // ...
}

so that everyone knows that the fall through is intentional.

The first case falls to the 2nd.

And the 3rd falls to the default case.

They’re all marked with comments to communicate the programmer’s intent.

Some style guides, like Douglas Crockford’s style guide, don’t all fall throughs on switch ever.

But this depends on our team’s preference.

default

Some people also argue whether the default case is required.

Some believe that they should always be included.

It’s more like people follow this pattern.

However, if there’s no default case that we can think of to add, we may omit it.

If we omit the default case, we may communicate that with comments so that everyone knows it’s intentional.

For instance, we can write:

switch (condition) {
  case 1:
    // ...
    break;
  case 2:
    // ...
    break;
  // no default
}

This way, we all know it’s not a mistake.

Conclusion

There’re several things to think about when we write switch statements.

breaks and default cases can be added or not, but we’ve to communicate our intent clearly.

This way, there won’t be any misunderstanding.