Node.js Best Practices — Syntax Issues

Like any kind of apps, JavaScript apps also have to be written well.

Otherwise, we run into all kinds of issues later on.

In this article, we’ll look at some best practices we should follow when writing Node apps.

Start a Code Block’s Curly Braces on the Same Line

The curly braces should be one the same line as the opening statement.

For example, instead of writing:

function foo()
{
  // code block
}

We write:

function foo() {
  // code block
}

This helps us avoid unexpected results.

If we have:

function foo()
{
  return;
  {
    bar: "fantastic"
  };
}

Then the return and the object is considered separate.

If we put the opening curly brace beside the return , then they’ll be considered one statement.

Separate Statements Properly

We have should separate statements properly.

For example, we can write:

function doThing() {
  // ...
}

doThing()

const items = [1, 2, 3]
items.forEach(console.log)

On the other hand, we should avoid typos like:

const m = new Map()
const a = [1,2,3]
[...m.values()].forEach(console.log)

The last 2 lines are considered to be the same statement and will throw a syntax error.

Another example would be:

const count = 2
(function foo() {
  // do something
}())

2 is considered to be a function with the parentheses on the new line.

To avoid all these issues, we should put semicolons to separate them.

Name Our Functions

We should name our functions so that we can trace functions by name when debugging.

Debugging using the core dump might be a challenge if we see significant issues with memory consumption from anonymous functions.

Use Naming Conventions for Variables, Constants, Functions, and Classes

Naming conventions for variables, constants, functions, and classes should follow common conventions.

Lower camel case should be used for naming constants, variables, and functions.

Upper camel case should be used for classes.

This helps us distinguish between plain variables or functions and classes.

Also, we should use descriptive names but keep them short.

Prefer const over let and Ditch the var

var shouldn’t be used for declaring variables anymore.

Their scope is tricky.

let and const are block-scoped, so where they’re available are clear.

const is better than let since we can’t reassign them to a new value.

Require Modules First, not Inside Functions

Modules should be required at the top of modules so that we can find errors and other issues when the module loads.

If they’re inside functions, then we see the issues with require only when we run the code.

So this just isn’t a good idea.

Also, requires are run synchronously by Node, so if they take a long time, then they may block code that is after the require.

Require Modules by Folders as Opposed to the Files Directly

We should place an index.js file that exposes the module’s intervals so consumers will pass through it.

This lets us create an interface that makes future changes easier without breaking the contract.

For example, we can write:

module.exports.foo = require("./foo");
module.exports.bar = require("./bar");

rather than:

module.exports.foo = require("./foo/foo.js");
module.exports.bar = require("./bar/bar.js");

to avoid importing JavaScript modules directly inside their folder.

Conclusion

We should consider syntax changes that make our lives easier and avoid errors.