JavaScript Best Practices — Spaces, Regex, and Errors

To make code easy to read and maintain, we should follow some best practices.

In this article, we’ll look at some best practices we should follow to make everyone’s lives easier.

Space Before Function Parenthesis

No space before function parenthesis is more conventional.

It makes sense because it doesn’t add much value.

function foo (x) {
  // ...
}

isn’t much different from:

function foo(x) {
  // ...
}

So we just live with the latter.

Spaces Inside of Parentheses

Spaces inside of parentheses don’t make much sense.

If we have:

foo( 'bar');

or:

foo('bar' );

Then that looks weird.

Instead, we write:

foo('bar');

Spacing Around Infix Operators

We should put spacing around infix operators to make them easier to read.

For instance, instead of writing:

var sum = 1+1;

We write:

var sum = 1 + 1;

Use the Strict Mode Directive

We should use strict mode to prevent mistakes.

Modules have strict mode enabled by default.

For instance, instead of writing:

function foo() {
  //...
}

We write:

"use strict";

function foo() {
  //...
}

We just put it on top so that it’s applied everywhere.

Spacing Around Colons of switch Statements

We should have conventional spacing around colons in switch statements.

For instance, instead of writing:

switch (a) {
  case 0: break;
  default: foo();
}

We write:

switch (a) {
  case 0:
    break;
  default:
    foo();
}

Symbol Description

Symbols should have descriptions so we know what we’re looking at.

For instance, instead of writing:

const foo = Symbol();

We write:

const foo = Symbol("description");

Usage of Spacing in Template Strings

We should follow conventional spacing ion template strings.

The expressions don’t need a space between them.

For instance, instead of writing:

`hello, ${ person.name}`;

We write:

`hello, ${person.name}`;

Spacing Between Template Tags and their Literals

There’s usually no space between template tags and their literals.

For instance, instead of writing;

let baz = func `foo bar`;

We write:

let baz = func`foo bar`;

Simplify Regexes by Making them Shorter, Consistent, and Safer

If there’s a shorter version of a pattern, then we should use it to create our regex.

For instance, instead of writing:

const regex = /[0-9]/;
const regex = /[^0-9]/;

We write:

const regex = /d/;
const regex = /D/;

to get digits.

And instead of writing:

const regex = /[a-zA-Z0-9_]/;
const regex = /[a-z0-9_]/i;

We write:

const regex = /w/;
const regex = /w/i;

to match alphanumeric characters.

And instead of writing:

const regex = /[^a-zA-Z0-9_]/;
const regex = /[^a-z0-9_]/i;

We write:

const regex = /W/;
const regex = /W/i;

to get nonalphanumeric characters.

Specific Parameter Name in catch Clauses

A specific parameter name makes more sense than different ones in catch clauses.

This way, we won’t be confused.

For instance, instead of writing:

try {} catch (badName) {}

We write:

try {} catch (error) {}

Move Function Definitions to the Highest Possible Scope

We move function definitions to the highest possible scope so that they can be better optimized and improve readability.

For instance, instead of writing;

export function doWork(foo) {
  function doBar(bar) {
    return bar === 'bar';
  }
  return doBar;
}

We return a function but don’t capture anything from the doWork ‘s scope.

Instead, we write:

function doBar(bar) {
  return bar === 'bar';
}

Enforce Correct Error Subclassing

The only way to create a subclass from an Error class is to use the extends keyword.

And we don’t pass in message to the parent constructor since it’s already set in the super call.

For instance, instead of writing:

class SuperError extends Error {
  constructor(message) {
    super(message);
    this.message = message;
    this.name = 'SuperError';
  }
}

We write:

class SuperError extends Error {
  constructor(message) {
    super(message);
    this.message = message;
    this.name = 'SuperError';
  }
}

Passing an Message Value when Throwing a Built-in Error

We can pass a message value to the Error constructor to make the error clearer.

For instance, instead of writing:

throw Error();

We write:

throw Error('Foo');

Conclusion

We can use conventional spacing to make our code clearer.

Also, we can create our own Error class.

If we create an Error instance, we should pass in an object to make them clearer.

If there are shorter patterns available for creating a regex, we should use it.