JavaScript Best Practices

Maintainable JavaScript — Comments and Statements

Spread the love

Creating maintainable JavaScript code is important if want to keep using the code.

In this article, we’ll look at the basics of creating maintainable JavaScript code by writing comments and statements properly.

Potential Author Errors

If there’re author errors in the code, then we should comment on them so that they can be fixed.

At least someone can check if it’s actually an error.

For example, if we have:

while (element && (element = element[axis])) {
  // NOTE: assignment
  if ((all || element[TAG_NAME]) &&
    (!fn || fn(element))) {
    return element;

then some people may think that the assignment operation in the while loop head is a mistake.

This is a valid syntax, so we can use it.

It’s not a mistake, so we tell readers that it’s not with a comment.

It may be flagged by some linting tools since we usually don’t use assignments in our loop header.

Browser-Specific Hacks

If we need to make our code work with multiple browsers, then we may need to write hacks to make them work with some specific browser.

This is common when we need to make our front end code work with Internet Explorer.

If we have hacks in our code, we should make comments on what we’re doing so people know what’s going on.

This should be less common as browsers become more standardized.

Documentation Comments

Comments can be used for documentation with programs like JSDoc.

For example, we can write:

  add 2 numbers together
  @method add
  @param {number} x - a number
  @param {number} y - another number
  @return {number} the sum of 2 numbers
function add(x, y) {
  return x + y;

We have the add function that has 2 parameters.

We add some comments about the parameters so we know the type of the parameters.

Also, we do the same with the return type.

This can be read with a documentation generator to create our documentation.

We should document all methods, including the expected arguments and possible return values.

Constructors should have comments with the custom type and expected arguments.

Other objects that have one or more methods can have comments on the methods.

They must be documented for proper documentation generation.

The document generator would determine how the comments should be formatted.


Statements like if or for can be used in 2 ways in JavaScript.

We can have the curly braces or we can skip them if our block is only one line long.

However, skipping the curly braces is bad since it’s hard to tell where the block starts or ends.

So instead of writing:

if (condition)


if (condition) doWork();


if (condition) { doWork(); }

We should write:

if (condition) {

Having the body below the first line is better than having it on the same line.

The curly-brace surrounds the block and it’s easy to tell where the block starts or ends with them.


Comments should be added for potential errors or hard to understand code.

Also, statements should be surrounded with curly braces.

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 *