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.
Maximum Number of Statements Per Line
We shouldn’t have too many statements per line.
For instance, we can write things like:
function foo () { let bar; let baz; if (condition) { bar = 1; } else { baz = 2; } return true; }
Instead, we write:
function foo() {
let bar;
let baz;
if (condition) {
bar = 1;
} else {
baz = 2;
}
return true;
}
Require Constructor Names to Begin with a Capital Letter
Constructor names start with a capital letter to distinguish from other identifiers.
For instance, we write;
const person = new Person();
It’s a convention that is commonly accepted so people will understand it.
Parentheses When Invoking a Constructor with no Arguments
We should always add parentheses to the constructor when we invoke them with no arguments.
We can skip the parentheses, but we should keep them.
Instead of writing:
const person = new Person;
We write:
const person = new Person();
Empty Line After Variable Declarations
We can group variable declarations together.
For instance, we can write:
const greet = "hello,",
const name = "james";
const foo = 12;
We can group them with empty lines to distinguish them easily.
Empty Line Before return Statements
An empty line before statements aren’t that useful, so we can skip them.
We can write:
function foo(baz) {
if (!baz) {
return;
}
return baz;
}
and save some space.
Newline After Each Call in a Method Chain
If we have long method chains, we should put a newline after each call.
For instance, we can write:
$("#p")
.css("color", "green")
.slideUp(2000)
.slideDown(2000);
instead of writing:
$("#p").css("color", "green").slideUp(2000).slideDown(2000);
Don’t Use Alert for Debugging
We shouldn’t use alert for debugging.
There are better alternatives like console and debugger for debugging.
However, they can used for showing alerts like it’s intended to.
Array Constructors
The Array constructor is good for creating empty arrays.
However, other things that it can do should be avoided in favor for array literals.
We can create an empty array by writing:
Array(10)
Then we get an array with 10 empty slots.
Then we can fill them with fill :
Array(10).fill().map((_, i) => i);
We call fill and map to fill the empty array with content.
Bitwise Operators
Since most people aren’t aware of JavaScript bitwise operators, we may want to check for them so that they won’t be used by mistake.
|| and && look like the | and & bitwise operators.
Use of caller/callee
We shouldn’t use arguments.caller and arguments.callee to get the caller and callee of a function.
It can’t be used in strict mode.
Lexical Declarations in case/default Clauses
We should use case and defaukt blocks so we can declare block scope variables with the same name in different blocks.
For instance, instead of writing:
switch (foo) {
case 1:
let x = 1;
break;
case 2:
const y = 2;
break;
case 3:
function f() {}
break;
default:
class C {}
}
We write:
switch (foo) {
case 1: {
let x = 1;
break;
}
case 2: {
const x = 2;
break;
}
case 3: {
function f() {}
break;
}
default: {
class C {}
}
}
We can declare x in different blocks since they’re block-scoped.
Modifying Variables of Class Declarations
We shouldn’t modify the value of class declarations.
So we shouldn’t write:
class A { }
A = 0;
We won’t get an error, but it’ll confusing to people.
No Comparing Against -0
=== doesn’t distinguish between 0 and -0.
So comparing them wouldn’t return what we expect.
For instance,e instead of writing:
if (x === -0) {
doSomething()
}
We should use Object.is for comparison, which does distinguish between +0 and -0:
if (Object.is(x, -0)) {
doSomething();
}
Conclusion
We shouldn’t have too many statements in one line.
Anything in the arguments object shouldn’t be used.
Bitwise operators are easily mistaken for boolean operators.
Use Object.is to compare against -0.
Constructors should always be invoked with parentheses.
