Low level issues

One of the justifications for using Comma First style is that it can help track missing and trailing commas. These are problematic because missing commas in variable declarations can lead to the leakage of global variables and trailing commas can lead to errors in older versions of IE.

A confusing aspect of JavaScript is that a function returns undefined if any of the following are true:
1. it does not execute a return statement before it exits
2. it executes return which does not specify a value explicitly
3. it executes return undefined
4. it executes return void followed by an expression (for example, a function call)
5.it executes return followed by any other expression which evaluates to undefined

If any code paths in a function return a value explicitly but some code path do not return a value explicitly, it might be a typing mistake, especially in a large function. In the following example:
1. a code path through the function returns a Boolean value true
2.  another code path does not return a value explicitly, therefore returns undefined implicitly

1. [] == false
2. [] == ![] 3. 3 == “03”

If one of those occurs in an innocent-looking statement such as a == b the actual problem is very difficult to spot.

Foo.prototype.bar = function bar() {};

Adding the second bar in the above example is optional.  If you leave off the function name then when the function throws an exception you are likely to get something similar to anonymous function in the stack trace.  If you provide the optional name for a function expression then you will get the name of the function expression in the stack trace.

The primary difference between function declarations and function expressions is that declarations are hoisted to the top of the scope in which they are defined, which allows you to write code that uses the function before its declaration.

For function expressions, you must define the function before it is used, otherwise it causes an error.

Due to these different behaviors, it is common to have guidelines as to which style of function should be used. There is really no correct or incorrect choice here, it is just a preference.

var fs = require(“fs”);

While require() may be called anywhere in code, some style guides prescribe that it should be called only in the top level of a module to make it easier to identify dependencies. For instance, it’s arguably harder to identify dependencies when they are deeply nested inside of functions and other statements:

function foo() {
if (condition) {
var fs = require(“fs”);
}
}

Since require() does a synchronous load, it can cause performance problems when used in other locations. Further, ES6 modules mandate that import and export statements can only occur in the top level of the module’s body.

These are the most common scenarios recommended in different style guides:
1. Two spaces, not longer and no tabs: Google, npm, Node.js, Idiomatic, Felix
2. Tabs: jQuery
3. Four spaces: Crockford

Unlike string literals in JavaScript, string literals within JSX attributes can’t contain escaped quotes. If you want to have e.g. a double quote within a JSX attribute value, you have to use single quotes as string delimiter.

if (foo) {
// …
} else {
// …
}

Of course, you could also have a style guide that disallows spaces around keywords.

// above comment
var foo = “bar”; // beside comment

The linebreaks (new lines) used in windows operating system are usually carriage returns (CR) followed by a line feed (LF) making it a carriage return line feed (CRLF) whereas Linux and Unix use a simple line feed (LF). The corresponding control sequences are “n” (for LF) and “rn” for (CRLF).

Many versioning systems (like git and subversion) can automatically ensure the correct ending. However to cover all contingencies, you can activate this rule.

var x = y | z;

function foo() {
var callee = arguments.callee;
}

To ensure that the lexical declaration only applies to the current case clause
wrap your clauses in blocks.

import { merge } from ‘module’;
import something from ‘another-module’;
import { find } from ‘module’;

function foo() {
// do nothing.
}

Especially, the empty block of arrow functions might be confusing developers.
It’s very similar to an empty object literal.

list.map(() => {}); // This is a block, would return undefined.
list.map(() => ({})); // This is an empty object.

The first is using setTimeout(), setInterval() or execScript() (Internet Explorer only), both of which can accept a string of JavaScript code as their first argument. For example:

“setTimeout(“alert(‘Hi!’);”, 100);”

This is considered an implied eval() because a string of JavaScript code is passed in to be interpreted. The same can be done with setInterval() and execScript(). Both interpret the JavaScript code in  the global scope. For  both setTimeout() and setInterval(), the first argument can also be a function, and that is considered safer and is more performant:

“setTimeout(function() {
alert(“Hi!”);
}, 100);”

The best practice is to always use a function for the first argument of setTimeout() and setInterval() (and avoid execScript()).

Note: It is expected for this rule to emit one error for each mixed operator in a pair. As a result, for each two consecutive mixed operators used, a distinct error will be displayed, pointing to where the specific operator that breaks the rule is used.

This rule disallows negated conditions in either of the following:
1. if statements which have an else branch
2. ternary expressions

While there are no performance differences between the two approaches, the byte savings and conciseness of the object literal form is what has made it the de facto way of creating new objects.

Some modules return a constructor which can potentially lead to code such as:
var appHeader = new require(‘app-header’);

Unfortunately, this introduces a high potential for confusion since the code author likely meant to write:
var appHeader = new (require(‘app-header’));

For this reason, it is usually best to disallow this particular expression.

Although possible, there aren’t any good reasons to use these primitive wrappers as constructors. They tend to confuse other developers more than anything else because they seem like they should act as primitives, but they do not.

The first problem is that primitive wrapper objects are, in fact, objects. That means typeof will return “object” instead of “string”, “number”, or “boolean”. The second problem comes with boolean objects. Every object is truthy, that means an instance of Boolean always resolves to true even when its actual value is false.

For these reasons, it’s considered a best practice to avoid using primitive wrapper types with new.

This rule can be also configured to fail when function parameters are modified. Side effects on parameters can cause counter-intuitive execution flow and make errors difficult to track down.

In order to avoid any confusion as to how to create the correct path, Node.js provides the path module. This module uses system-specific information to always return the correct value.

Why would you want to restrict imports?
1. Some imports might not make sense in a particular environment. For example, Node.js’ fs module would not make sense in an environment that didn’t have a file system.
2. Some modules provide similar or identical functionality, think lodash and underscore. Your project may have standardized on a module. You want to make sure that the other alternatives are not being used as this would unnecessarily bloat the project and provide a higher maintenance cost of two dependencies when one would suffice.

Why would you want to restrict a module?
Disallowing usage of specific Node.js modules can be useful if you want to limit the available methods a developer can use. For example, you can block usage of the fs module if you want to disallow file system access.

Rather than creating separate rules for every language feature you want to turn off, this rule allows you to configure the syntax elements you want to restrict use of. These elements are represented by their ESTree node types. For example, a function declaration is represented by FunctionDeclaration and the with statement is represented by WithStatement. You may find the full list of AST node names you can use on GitHub and use the online parser to see what type of nodes your code consists of.

You can also specify AST selectors to restrict, allowing much more precise control over syntax patterns.

The only time you would compare a variable against itself is when you are testing for NaN. However, it is far more appropriate to use typeof x === ‘number’ && isNaN(x) or the Number.isNaN ES2015 function for that use case rather than leaving the reader of the code to determine the intent of self comparison.

This rule restricts what can be thrown as an exception. When it was first created, it only prevented literals from being thrown (hence the name), but it has now been expanded to only allow expressions which have a possibility of being an Error object.

There is actually a long history of using dangling underscores to indicate “private” members of objects in JavaScript (though JavaScript doesn’t have truly private members, this convention served as a warning). This began with SpiderMonkey adding nonstandard methods such as __defineGetter__(). The intent with the underscores was to make it obvious that this method was special in some way. Since that time, using a single underscore prefix has become popular as a way to indicate “private” members of objects.

Whether or not you choose to allow dangling underscores in identifiers is purely a convention and has no effect on performance, readability, or complexity. It’s purely a preference.

Another common mistake is using a single variable as both the conditional test and the consequent. In such cases, the logical OR can be used to provide the same functionality.

For example, n + 1; is not a syntax error, but it might be a typing mistake where a programmer meant an assignment statement n += 1; instead.

In ES6, block-level bindings (let and const) introduce a “temporal dead zone” where a ReferenceError will be thrown with any attempt to access the variable before its declaration.

But Function.prototype.call() and Function.prototype.apply() are slower than the normal function invocation.

This code is likely the result of refactoring where a variable was removed from the concatenation (such as “a” + b + “b”). In such a case, the concatenation isn’t important and the code can be rewritten as:

var foo = “ab”;

There are two schools of thought in this regard:
1. There should be just one variable declaration for all variables in the function. That declaration typically appears at the top of the function.
2. You should use one variable declaration for each variable you want to define.

The single-declaration school of thought is based in pre-ECMAScript 6 behaviors, where there was no such thing as block scope, only function scope. Since all var statements are hoisted to the top of the function anyway, some believe that declaring all variables in a single declaration at the top of the function removes confusion around scoping rules.

For example, arrow functions are automatically bound to their surrounding scope/context. This provides an alternative to the pre-ES6 standard of explicitly binding function expressions to achieve similar behavior.

Additionally, arrow functions are:
1. less verbose, and easier to reason about.
2. bound lexically regardless of where or when they are invoked.

const declaration tells readers, “this variable is never reassigned,” reducing cognitive load and improving maintainability.

arguments does not have methods of Array.prototype, so it’s a bit of an inconvenience.

There are, however, some occasions when you must use quotes:
1. If you are using an ECMAScript 3 JavaScript engine (such as IE8) and you want to use a keyword (such as if) as a property name. This restriction was removed in ECMAScript 5.
2. You want to use a non-identifier character in your property name, such as having a property with a space like “one two”.

This confusion led to the suggestion that you always use the radix parameter to parseInt() to eliminate unintended consequences.

ECMAScript 5 changed the behavior of parseInt() so that it no longer autodetects octal literals and instead treats them as decimal literals. However, the differences between hexadecimal and decimal interpretation of the first parameter causes many developers to continue using the radix parameter to ensure the string is interpreted in the intended way.

On the other hand, if the code is targeting only ES5-compliant environments passing the radix 10 may be redundant. In such a case you might want to disallow using such a radix.

On the first line, the JavaScript engine will automatically insert a semicolon, so this is not considered a syntax error. The JavaScript engine still knows how to interpret the line and knows that the line end indicates the end of the statement.

In the debate over ASI, there are generally two schools of thought. The first is that we should treat ASI as if it didn’t exist and always include semicolons manually. The rationale is that it’s easier to always include semicolons than to try to remember when they are or are not required, and thus decreases the possibility of introducing an error.

However, the ASI mechanism can sometimes be tricky to people who are using semicolons.

Effectively, a semicolon is inserted after the return statement, causing the code below it (a labeled literal inside a block) to be unreachable. This rule and the no-unreachable rule will protect your code from such cases.

On the other side of the argument are those who says that since semicolons are inserted automatically, they are optional and do not need to be inserted manually. However, the ASI mechanism can also be tricky to people who don’t use semicolons.

In this example, a semicolon will not be inserted after the first line, causing a run-time error (because an empty object is called as if it’s a function). The no-unexpected-multiline rule can protect your code from such cases.

Although ASI allows for more freedom over your coding style, it can also make your code behave in an unexpected way, whether you use semicolons or not. Therefore, it is best to know when ASI takes place and when it does not, and have ESLint protect your code from these potentially unexpected cases. In short, as once described by Isaac Schlueter, a n character always ends a statement (just like a semicolon) unless one of the following is true:

1. The statement has an unclosed paren, array literal, or object literal or ends in some other way that is not a valid way to end a statement. (For instance, ending with . or ,.)
2. The line is — or ++ (in which case it will decrement/increment the next token.)
3. It is a for(), while(), do, if(), or else, and there is no {
4. The next line starts with [, (, +, *, /, -, ,, ., or some other binary operator that can only be found between two tokens in a single expression.

Disallowing or enforcing space around a semicolon can improve the readability of your program.

if (“red” === color) { // … }

This is called a Yoda condition because it reads as, “if red equals the color”, similar to the way the Star Wars character Yoda speaks. Compare to the other way of arranging the operands:

if (color === “red”) { // .. }

This typically reads, “if the color equals red”, which is arguably a more natural way to describe the comparison.

Proponents of Yoda conditions highlight that it is impossible to mistakenly use = instead of == because you cannot assign to a literal value. Doing so will cause a syntax error and you will be informed of the mistake early on. This practice was therefore very common in early programming where tools were not yet available.

Opponents of Yoda conditions point out that tooling has made us better programmers because tools will catch the mistaken use of = instead of == (ESLint will catch this for you). Therefore, they argue, the utility of the pattern doesn’t outweigh the readability hit the code takes while using Yoda conditions.