npm i --save dexpress
Add a .eslintrc
:
{
"extends": "dnode"
}
A method not using this can be static, yes, but I wouldn't force it. There can be reasons a method should be declared used with an instance (non static) independently if the method really use this or not.
Trailing commas always if multiline. Exception for functions because node doesn't allow it.
A function without a return
returns implicit undefined
. So if I have
one case which returns something and other cases which not, I don't
write a return;
or return undefined;
.
Use return;
or return undefined;
if nothing should be returned:
function example(example) {
if (example === 'example') {
return example;
}
return;
}
Just skip the unneeded returns and rely on the implicit return
undefined
:
function example(example) {
if (example === 'example') {
return example;
}
}
I don't like to force the use of require
in a global way. Sometimes
its just shorter to use it inside a structure. Like inside an object for
the lib.js
.
Define first const
variables for all require
:
const Example = require('./Example');
module.exports = {
Example,
};
Just use require
inside the object:
module.exports = {
Example: require('./Example'),
};
If using require it can be smart to chain and group the require together with other sequences.
Using always new lines to separate require and another sequences:
const app = require('express')();
app.listen(process.env.PORT);
Group the lines by logically:
const app = require('express')();
app.listen(process.env.PORT);
Dynamic require can not be analysed by static code analyser. But they allow a lot of convenient structures.
Manually require all files statically into an object:
const examples = {
a: require('./a'),
b: require('./b'),
c: require('./c'),
};
const example = 'a';
examples[example]();
Use dynamic require for a convenient structure:
const example = 'a';
require(`./${example}`)();
Sometimes the async operations depending on each other in a loop. So its a legal use of await in a loop.
There isn't something bad in using console.log
in node. 12factor say
explicit logging should be done by stdout
which is console.log
.
Sometimes there is an else with a following if which is not depending to each other. In this cases its not usefull to transform this into an else if.
JavaScript doesn't have overloaded functions. So to define functions which allows multiple type of parameters I think reassign this parameter is a short and effective way to handle this.
Define new variables:
function example(examples) {
let checkedExamples = examples;
if (!Array.isArray(checkedExamples)) {
checkedExamples = [checkedExamples];
}
}
Just reassign the parameters:
function example(examples) {
if (!Array.isArray(examples)) {
examples = [examples];
}
}
JavaScript allow to iterate over arrays/objects with for ... in
and
for ... of
. I want to use these keywords instead of functions like
.forEach
because its better readable.
.forEach
with arrow function:
examples.forEach(example => {
});
Use the native keywords of JavaScript:
for (const example of examples) {
}
It can make sense to use the same variables in different layers, especially for closures in array functions. But still care about the readability.
Numerate or prefix variables:
const element = elements.map(element2 => element2.valid)[0];
// or
const element = elements.map(innerElement => innerElement.valid)[0];
Use the same variable names if the readability is still given:
const element = elements.map(element => element.valid)[0];
There is not a problem in using underscores in the beginning of a variable or function, especially if its not used to hint private or protected e.g. in translation function '__()'.