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 = obj.foo.bar.baz;
Now we can just reference baz instead of obj.foo.bar.baz .
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.
JSDoc
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.
Markdown
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;
};
Conclusion
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.
