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.
No Assignment Operators in Conditional Statements
Assignment operators in conditional statements are probably a mistake.
If that’s all we have, then we should check if that’s actually what we want.
For instance, instead of writing:
if (user.title = "manager") {
// ...
}
We write:
if (user.title === "manager") {
// ...
}
No Arrow Functions that can be confused with Comparisons
It’s easy to confuse the arrow of the arrow function and comparison operators.
For instance, if we have:
const foo = a => 1 ? 2 : 3;
Then we can be confused easily.
To make it clear, we write:
const foo = (a) => (1 ? 2 : 3);
Remove console Before Going to Production
We should remove console before our code goes to production.
It’s good for debugging but not suitable for end-users to view the output.
If we have something like:
console.log("foo bar");
We should remove them.
Don’t Modify Variables that are Declared Using const
Variables shouldn’t be reassigned if they’re declared with const .
We’ll get an error if we try to do so.
So instead of writing:
const a = 0;
a = 2;
or:
const a = 0;
a += 1;
We write:
const a = 0;
const b = a + 1;
No Constant Expressions in Conditions
We shouldn’t have constant expressions in conditions.
They either always run or never run.
This makes them useless.
For instance, instead of writing:
if (false) {
doSomething();
}
which never runs, we write:
if (foo && bar) {
doSomething();
}
Returning Value in Constructor
If we return a value in a constructor, then the object is returned.
Otherwise, we return the instance of the constructor.
The latter case is probably what most people want.
So we shouldn’t return our own object most of the time.
Instead of writing:
class A {
constructor(a) {
this.a = a;
return a;
}
}
We write:
class A {
constructor(a) {
this.a = a;
}
}
to return an instance of A instead of the value of a .
continue Statements
contunue statements let us skip to the next iteration of the loop.
For instance, we can write:
for (i = 0; i < 10; i++) {
if (i >= 5) {
continue;
}
//...
}
to skip to the next iteration if i is bigger than or equal to 5.
This can be useful.
Control Characters in Regular Expressions
Control characters are rarely used in regex or JavaScript in general, so it’s probably a mistake to have them.
Instead of writing:
const pattern1 = /x1f/;
const pattern2 = new RegExp("x1f");
We write:
const pattern1 = /d/;
const pattern2 = new RegExp("d");
Don’t Use debugger in Production Code
Before our code goes to production, we should remove all debugger statements so that the app runs properly.
If we don’t, then it’ll pause when we hit the statement.
Instead of writing:
function toBool(x) {
debugger;
return Boolean(x);
}
We write:
function toBool(x) {
return Boolean(x);
}
No Deleting Variables
The delete operator is only used for deleting variable properties.
It can’t be use with variables.
So we shouldn’t have code like:
let x;
delete x;
No Regular Expressions That Look Like Division
We shouldn’t have a regex that looks like division.
For instance, code like:
/=foo/
is probably a mistake.
Instead, we write:
/foo/
No Duplicate Arguments in Function Definitions
Duplicate parameters is an illegal syntax in JavaScript, so we shouldn’t write that.
For instance, instead of writing:
function foo(a, b, a) {
console.log(a);
}
We write:
function foo(a, b) {
console.log(a);
}
No Duplicate Name in Class Members
We shoukldn’r have duplicate names in class members
The one that comes last will overwrite the earlier instances.
So instead of writing:
class Foo {
bar() {
console.log("bar");
}
bar() {
console.log("baz");
}
}
We write:
class Foo {
bar() {
console.log("baz");
}
}
Conclusion
We shouldn’t have duplicate parameters and class members.
We probably shouldn’t have assignment operators in if statements.
console and debugger don’t belong in production code.
