JavaScript Best Practices — Code That We Shouldn’t Have

JavaScript is a very forgiving language. It’s easy to write code that runs but has mistakes in it.

In this article, we look at some code that we shouldn’t add to our JavaScript codebase.

No Unnecessary Labels

JavaScript has labels that we can label parts of our code. For instance, if we have 2 loops, we can label them as follows:

A: while (a) {
  break A;
}

B: while (b) {
  break B;
}

In the code above, we have label A to label the first while loop and B to label the second while loop.

However, the example above is useless because the label is just referenced within itself. So the code above is the same as:

while (a) {
  break;
}

while (b) {
  break;
}

Therefore, the labels are useless.

We should use labels to only reference other pieces of code which the label is used to label. For instance, we can write the following code:

A: while (a) {
  break B;
}

B: while (b) {
  break A;
}

No Case Statement Fallthrough

In switch blocks, we can write case statements or blocks without the break keyword at the end of each case .

This isn’t good because all the case statements or blocks will run even if a matching case is found within the switch statement.

For instance, if we have:

let foo = 1;
let bar;
switch (foo) {
  case 1:
    bar = 'x';
  case 2:
    bar = 'y';
}

Then we’ll see that bar is 'y' even though foo is 1, which is probably not what we want.

The correct way to write the switch statement is to write the following:

let foo = 1;
let bar;
switch (foo) {
  case 1:
    bar = 'x';
    break;
  case 2:
    bar = 'y';
    break;
}

Then bar will be 'x' as we expected. Alternatively, we can also write return instead of break as follows:

let foo = 1;
const baz = (foo) => {
  switch (foo) {
    case 1:
      return 'x';
    case 2:
      return 'y';
  }
}

let bar = baz(foo);

In the code above, we have return statements instead of break, and we placed the switch statement in the function so we can get the return value when calling it.

It’ll give us the same result as using break since it ends the code execution of the function.

No Floating Decimals

Floating decimals can be before or after a number in JavaScript. For instance, we can write the following:

let num1 = .1;
let num2 = 3.;
let num3 = -.5;

In the code above, we defined numbers with decimal points before or after a number.

This isn’t good because it’s not clear that the dot is for the dot operator for accessing properties or whether it’s a decimal point.

Instead, we should just put in the leading and trailing zeroes as follows:

let num1 = 0.1;
let num2 = 3.0;
let num3 = -0.5;

Photo by Vladislav Klapin on Unsplash

Assignment to Native Objects or Read-Only Global Variables

Read-only global variables like window or Object are read-only. Therefore, we shouldn’t be assigning new values to it.

For instance, we don’t want to do things like:

window = {};

since we don’t want window to be an empty object. Other things we don’t want include code like:

Object = null;
undefined = 1;
null = 2;

JavaScript strict mode should prevent these assignments from happening. If we didn’t use strict mode, then we should make sure that we don’t do things like this.

Modules are automatically set to use strict mode, so we don’t have to worry about this.

No Type Conversion with Shorter Notations

We can use the unary + , - , or ~ to convert values to numbers or boolean.

They aren’t very clear to some people, so we may want to limit their use. Therefore, instead of writing:

let b = !!foo;
let c = +'2';

We should convert them explicitly with built-in JavaScript functions as follows:

let b = Boolean(foo);
let c = Number('2');

Conclusion

We shouldn’t write code that is useless or don’t do what we expect them to. For instance, case statements and blocks in switch statements should always have break or return added.

Decimals should either not be used or we add leading and trailing zeroes to make it clear.

Also, we should never assign native global objects with our own values.

Finally, we may want to convert data types explicitly with our own code to make our type conversion code more clear.