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.
Getter and Setter Pairs in Objects and Classes
We should have getter and setter pairs in our objects.
Without getters, properties can’t be read, so it’s not used.
For instance, instead of writing:
const obj = {
set a(value) {
this.val = value;
}
};
We write:
const obj = {
set a(value) {
this.val = value;
},
get a() {
return this.val;
}
};
Line Breaks After Opening and Before Closing Array Brackets
We may put line breaks before the opening and closing brackets.
It’s clearer to have them for long arrays
For instance, instead of writing:
const arr= [1, 2, 3, 4, 5];
We write:
const arr = [
1, 2, 3, 4, 5
];
Spaces Inside of Brackets
We can line without spaces inside brackets.
So we can write:
const arr = ['foo', 'bar'];
and it’s clear to read.
Return Statements in Callbacks of Array Methods
We always need to return something in array methods.
Methods like reduce , Array.from , filter , map , some , every , etc. return things in methods.
For instance, we shouldn’t write things like:
const indexes = arr.reduce((foo, item, index) => {
foo[item] = index;
}, {});
or:
const foo = Array.from(elements, (element) => {
if (element.tagName === "DIV") {
return true;
}
});
Instead, we should write:
const sum = arr.reduce((a, b) => a + b, 0);
We return the result of the combination of the values with reduce .
Or we can write:
const foo = Array.from(elements, (element) => {
if (element.tagName === "DIV") {
return true;
}
return false;
});
Some methods like forEach don’t need to return something since we can’t do much with the return value.
But we can return early to move to the next iteration:
arr.forEach((item) => {
if (item < 0) {
return;
}
doSomething(item);
});
Line Breaks Between Array Elements
We may put long expressions in our array.
For instance, we can write:
const arr = [
function foo() {
doWork();
},
function bar() {
doWork();
}
];
We have 2 functions which are long, so we put them in their own line.
Braces in Arrow Function Body
Braces in the arrow function body can help with increasing clarity.
For instance, we can write:
const foo = () => {
return 0;
};
instead of writing:
const foo = () => 0;
We know we’re returning something for sure with the return keyword.
Parentheses in Arrow Function Arguments
Parentheses are useful for delimiting parameters.
For instance, we can write:
(a) => {}
to make reading parameters easier.
A Space Before or After Arrow Function’s Arrow
We should definitely put spaces between the arrow of an arrow function.
For instance, instead of writing:
(a)=>{}
or:
a=> a;
We write:
(a) => {}
Treat var as Block Scoped
If we use var to declare variables, they should be used as block-scoped variables.
For instance, we shouldn’t write something like:
function doIf() {
if (true) {
var build = true;
}
console.log(build);
}
or:
function doIfElse() {
if (true) {
var build = true;
} else {
var build = false;
}
}
Instead, we write:
const doIf = () => {
var build;
if (true) {
build = true;
}
console.log(build);
}
or:
const doIfElse = () => {
var build;
if (true) {
build = true;
} else {
build = false;
}
}
We shouldn’t use the non-block-scope features of var like hoisting or accessing var variables outside a block in a function.
They just trick lots of people.
Spaces Inside of Blocks After Opening Block and Before Closing Block
It’s good to have spaces inside blocks to make them readable.
For instance, instead of writing:
function foo() {return false;}
We write:
function foo() { return false; }
It’s just much clearer to have the spaces at the opening and closing.
Conclusion
Single spaces and extra rows are good for readability.
We should use array methods in the way they’re intended.
