JavaScript Best Practices

JavaScript Best Practices — Names and Comments

Spread the love

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 practices for naming things in JavaScript projects.

We should look at the proper uses of JSDoc.

File and Module Names

Name files in lower camelCase.

For instance, we can name a file fooBar.js .

Class Names

Class names should be PacalCase. For instance, we can write:

class FooBar {

Method Names

Meth names should be written in lower camel case.

For instance, we should write:

class FooBas {
  doSomething() {

If we have getters and setters, then we should make sure that we have names that reflect what they do.

For instance, we should name getters with names like getFoo . We can also name a method isFoo or hasFoo if they return a boolean.

If we have a setter, we should name them with names like setFoo .

Enum Names

Enum names should be UpperCamleCase.

For instance, we can define an enum by creating an object by writing:

const Unit = {
  METER: 'meter',
  FOOT: 'foot',

Unit is the enum name.

Also, we should use a singular noun.

Constant Names

Constant names should be named in CONSTANT_CASE.

The names upper case letters, with words separated by underscores.

Constants have const declaration, but not all module-local const s are constants.

const values can be mutable, just that they can’t be assigned a new value.

Local Aliases

We should create local aliases to help with readability.

For instance, if we want to reference an object with deeply nested properties, we can create an alias by writing:

const baz =;

Now we can just reference baz instead of .

It’s shorter and easier to read.

Aliases must be const so they can’t be reassigned to a new value.

Non-Constant Field Names

Field names, static or otherwise, should be written in camelCase.

For instance, we can have names like foo or numFoo for non-constant field names.

Local Variable Names

Local variable names are written in camelCase, except when we have constants.

Constant names in function scopes should also be written in camelCase.

camelCase should be used even if the variable holds a constructor.


We can write JSDoc comments to document our code.

For instance, we can write:

 * Bunch of text,
 * and more text.
 * @param {number} num A number to do something to.
function doSomething(num) {

The comment is above the function and it has a @param annotation for explaining the meaning of parameters.

We can use /** and */ on their own lines to extend the comment block.

There are many tools to extract comments from JSDoc.

Also, there are tools to perform code validation and optimization according to the comments.


We write JSDoc comments in Markdown.

We follow the Markdown syntax when writing comments.

For instance, we write:

 * Computes volume based on
 *  - length
 *  - width
 *  - height

We have - to denote a list entry for example.

JSDoc Tags

There are various tags that we can use with JSDoc.

@param is a commonly used tag as we saw above.

Other common tags include:

  • @constructor — mark function as a constructor
  • @enum — mark object as enum
  • @extends — mark class inheritance structure
  • @implements — mark the interface that’s implemented
  • @return — specify the return type of a function

There are many more tags that we can add to our comments to document our code.

Line Wrapping

Line-wrapped block tags should be indented 4 paces.

We shouldn’t align comment text horizontally.

For instance, we can write:

 * @param {string} very very very very long
 *     description
 * @return {number} very very very very longtoo long
 *     description
function bar(foo) {
  return 5;


We can comment on our code with JSDoc, which is based on Markdown.

Long lines should be wrapped and wrapped lines should be indented.

Also, the casing of names is pretty standard in JavaScript. We have camelCase for most names, and PascalCase and upper case for others.

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 *