JavaScript Best Practices

JavaScript Best Practices — Spaces, Functions, Negations

Spread the love

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.

No Functions in Loops

Functions in loops result in errors because of how they’re created in a loop.

With var , the loop index is always the last since it doesn’t get passed into the variable function until it’s done.

Instead of writing:

for (var i = 0; i < 10; i++) {
  funcs[i] = function() {
    return i;

We write:

for (let i = 0; i < 10; i++) {
  funcs[i] = function() {
    return i;

to get the expected value of i in the function returned, which is the index value of the loop during each iteration.

With var , the value will always be 10.

No Magic Numbers

Magic numbers are hard to understand and we’ve to change them in multiple places, so we should assign them to named constants.

Instead of writing:

const now =;
const anHourLater = now + (60 * 60 * 1000);

We write:

const SECONDS_IN_HOUR = 60 * 60;

No Characters which are Made with Multiple Code Points in Character Class Syntax

We shouldn’t have characters that are made of multiple code points.

This is because they’ll be matched to either character.

So w should write:


instead of:


No Mixes of Different Operators

Mixing different operators are confusing, so we shouldn’t do them.

For instance, instead of writing:

const foo = a && b || c || d;

We put in some parentheses to separate the expressions:

const foo = (a && b) || c || d;

require Calls to be Mixed with Regular Variable Declarations

Instead of writing require calls separated with regular variables with commas, we just write them all in their own line for clarity.

For instance, instead of writing:

const eventEmitter = require('events').EventEmitter,
  foo = 10,
  bar = 'baz';

We write:

const eventEmitter = require('events').EventEmitter;
const foo = 10;
let bar = 'baz';

No Mixing Spaces and Tabs for Indentation

Mixing spaces and tabs for indentation will cause issues with parsing and formatting with text editors, so we should convert tabs into spaces.

No Use of Chained Assignment Expressions

Chained assignment expressions will create global variables.

The ones that aren’t next to the variable declaration keyword will be global.

They’re also hard to read.

For instance, if we have:

const foo = bar = 0;

then bar is global and foo is constant.

Instead, we separate them for clarity:

const foo = -0;
const bar = 0;

No Multiple Spaces

One space is enough for anything other than indentation.

So we should keep a single space for expressions.

Instead of writing:

if(foo  === "baz") {}

We write:

if(foo === "baz") {}

No Multiline Strings

We shouldn’t write multiline strings with a backslash.

It’s not standard and it’s bad.

So instead of writing:

let x = "line 1
  line 2";

We write:

let x = `line 1
  line 2`;

We use template strings instead of regular strings for multiline strings.

No Multiple Empty Lines

Multiple empty lines aren’t useful for separating code.

We just need one.

So instead of writing:

let foo = 5;

var bar = 3;

We write:

let foo = 5;

var bar = 3;

No Reassignment of Native Objects

We should never reassign native objects to anything else.

We don’t want any unexpected results because of that.

So instead of writing:

Object = null
undefined = 1

We write:

let foo = null;
let bar = 1;

No Negated Conditions

Negated conditions are hard to read, so we should avoid them as much as possible.

For instance, instead of writing:

if (!a) {
} else {

We write:

if (a) {
} else {


We don’t need multiple spaces in our code.

Negated conditions should be replaced with positive ones.

Magic numbers should be replaced with named constants.

Be careful that we don’t have regex with characters that have multiple code points.

Spaces and tabs shouldn’t be mixed.

By John Au-Yeung

Web developer specializing in React, Vue, and front end development.

Leave a Reply

Your email address will not be published. Required fields are marked *