JavaScript Best Practices — Comparisons

JavaScript is an easy to learn programming language. It’s easy to write programs that run and does something. However, it’s hard to account for all the uses cases and write robust JavaScript code.

In this article, we’ll look at the best ways to work with switch statements and other comparisons statements.

Use Braces to Create Blocks in switch and case Statements

If we create blocks in switch and case statements, then we can enclose block-scoped variables.

So instead of writing:

switch (foo) {  
  case 1:  
    let x = 1;  
    break;  
  case 2:  
    const y = 2;  
    break;  
    //...  
}

We can write:

switch (foo) {  
  case 1: {  
    let x = 1;  
    break;  
  }  
  case 2: {  
    let x = 2;  
    break;  
  }  
  //...  
}

We can use x twice since x isn’t available outside the case block.

Terneries Shouldn’t be Nested

Ternary expressions shouldn’t be nested since they’re hard to read.

They should also be short.

For instance, instead of writing:

const foo = val1 === val2 ?  
  "foo" :  
  val3 > val4 ? "baz" : null;

As we can see, that’s hard to understand.

Therefore, we should write the following instead:

const foo = val1 === val2 ?  
  "foo" : "baz";

Avoid Useless Ternary Expressions

We shouldn’t have useless ternary expressions.

For instance, the following isn’t needed:

const baz = c ? false : true;

If c is a boolean, we can just assign it directly to baz .

If it’s not, we can use the Boolean function to convert it to a boolean.

So we can write:

const baz = !Boolean(c);

instead.

Enclosed Expressions with Mixed Operators in Parentheses

We should enclose expressions with mixed operators in parentheses to make them easier to read.

For instance, we shouldn’t write:

const foo = a && b < 5 || c < 3 || d + 1 === 0;

Instead, we should write:

const foo = ((a && b < 5) || (c < 3) || (d + 1)) === 0;

Now we can see the expressions clearly since they’re separated by parentheses.

Blocks

There are some things to consider when we’re creating blocks.

Use Braces with Multiline Blocks

If we have blocks, then we should dd braces whether they’re required or not.

For instance, instead of writing:

if (test)  
  return true;

We write:

if (test) {  
  return true;  
}

Likewise, with functions, instead of writing:

function foo() { return true; }

We write:

function foo() {   
  return true;   
}

If we’re Using Multiline Blocks with if and else, put else on the Same Line with if Block’s Closing Brace

For instance, instead of writing:

if (test) {  
  foo();  
  bar();  
}  
else {  
  baz();  
}

We write:

if (test) {  
  foo();  
  bar();  
} else {  
  baz();  
}

It saves some space without impacting readability.

If an if Block Always Runs a return Statement, the Subsequent else Block isn’t Necessary

If we have an if block that always returns, then the else block will never be run.

Therefore, we should remove the else block and put the return outside it.

For instance, instead of writing:

const foo = () => {  
  if (x) {  
    return x;  
  } else {  
    return y;  
  }  
}

We write:

const foo = () => {  
  if (x) {  
    return x;  
  }  
  return y;  
}

Control Statements

There are better ways to deal with control statements than others in JavaScript.

If Our Control Statements are too Long, then Each Condition Should be in a New Line

For instance, if we have:

if ((foo === 123 || bar === 'abc') && suprSuperSuperLong() && isSuprSuperSuperLong()) {  
  doSomething();  
}

Then we should tidy it up by writing:

if (  
  (foo === 123 || bar === 'abc') &&  
  suprSuperSuperLong() &&  
  isSuprSuperSuperLong()  
) {  
  doSomething();  
}

This is much easier to read than the first example.

No Selection Operator in Place of Control Statements

Using if is easier to understand than using the && operator to run something if a condition is true .

For instance, instead of writing:

canRun && run();

We write:

if (canRun) {  
  run();  
}

Conclusion

We should surround swiotchj and case statements with braces so that we can use block-scoped variables with them.

If we long boolean expressions, then we should break them into their own line.