Rule Description KPI URL
accessor-pairs It’s a common mistake in JavaScript to create an object with just a setter for a property but never have a corresponding getter defined for it. Without a getter, you cannot read the property, so it ends up not being used. Maintainability
array-bracket-newline A number of style guides require or disallow line breaks inside of array brackets. Understandability
array-bracket-spacing A number of style guides require or disallow spaces between array brackets and other tokens. This rule applies to both array literals and destructuring assignments (ECMAScript 6). Understandability
array-callback-return Array has several methods for filtering, mapping, and folding. If we forget to write return statement in a callback of those, it’s probably a mistake. Accuracy
array-element-newline A number of style guides require or disallow line breaks between array elements. Understandability
arrow-body-style Arrow functions have two syntactic forms for their function bodies. They may be defined with a block body (denoted by curly braces) () => { … } or with a single expression () => …, whose value is implicitly returned. Understandability
arrow-parens Arrow functions can omit parentheses when they have exactly one parameter. In all other cases the parameter(s) must be wrapped in parentheses. This rule enforces the consistent use of parentheses in arrow functions. Understandability
arrow-spacing This rule normalize style of spacing before/after an arrow function’s arrow(=>). Understandability
block-spacing This rule enforces consistent spacing inside an open block token and the next token on the same line. This rule also enforces consistent spacing inside a close block token and previous token on the same line. Understandability
brace-style Brace style is closely related to indent style in programming and describes the placement of braces relative to their control statement and body. There are probably a dozen, if not more, brace styles in the world. The one true brace style is one of the most common brace styles in JavaScript, in which the opening brace of a block is placed on the same line as its corresponding statement or declaration.While no style is considered better than the other, most developers agree that having a consistent style throughout a project is important for its long-term maintainability. Understandability
camelcase When it comes to naming variables, style guides generally fall into one of two camps: camelcase (variableName) and underscores (variable_name). This rule focuses on using the camelcase approach. If your style guide calls for camelCasing your variable names, then this rule is for you! Understandability
capitalized-comments Comments are useful for leaving information for future developers. In order for that information to be useful and not distracting, it is sometimes desirable for comments to follow a particular style. One element of comment formatting styles is whether the first word of a comment should be capitalized or lowercase. In general, no comment style is any more or less valid than any others, but many developers would agree that a consistent style can improve a project’s maintainability. Understandability
class-methods-use-this If a class method does not use this, it can sometimes be made into a static function. If you do convert the method into a static function, instances of the class that call that particular method have to be converted to a static call as well (MyClass.callStaticMethod()) Maintainability
comma-dangle Trailing commas in object literals are valid according to the ECMAScript 5 (and ECMAScript 3!) spec. However, IE8 (when not in IE8 document mode) and below will throw an error when it encounters trailing commas in JavaScript. Trailing commas simplify adding and removing items to objects and arrays, since only the lines you are modifying must be touched. Another argument in favor of trailing commas is that it improves the clarity of diffs when an item is added or removed from an object or array. Understandability
comma-spacing Spacing around commas improve readability of a list of items. Although most of the style guidelines for languages prescribe adding a space after a comma and not before it, it is subjective to the preferences of a project. Understandability
comma-style The Comma Style rule enforces styles for comma-separated lists. There are two comma styles primarily used in JavaScript:
1. The standard style, in which commas are placed at the end of the current line
2. Comma First style, in which commas are placed at the start of the next line

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.

complexity Cyclomatic complexity measures the number of linearly independent paths through a program’s source code. This rule allows setting a cyclomatic complexity threshold. Maintainability
computed-property-spacing While formatting preferences are very personal, a number of style guides require or disallow spaces between computed properties in the following situations: Understandability
consistent-return Unlike statically-typed languages which enforce that a function returns a specified type of value, JavaScript allows different code paths in a function to return different types of values.

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) 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

consistent-this It is often necessary to capture the current execution context in order to make it available subsequently. There are many commonly used aliases for this such as that, self or me. It is desirable to ensure that whichever alias the team agrees upon is used consistently throughout the application. Understandability
curly JavaScript allows the omission of curly braces when a block contains only one statement. However, it is considered by many to be best practice to never omit curly braces around blocks, even when they are optional, because it can lead to bugs and reduces code clarity. There are, however, some who prefer to only use braces when there is more than one statement to be executed. Maintainability
dot-location JavaScript allows you to place newlines before or after a dot in a member expression. Consistency in placing a newline before or after the dot can greatly increase readability. Understandability
dot-notation In JavaScript, one can access properties using the dot notation ( or square-bracket notation (foo[“bar”]). However, the dot notation is often preferred because it is easier to read, less verbose, and works better with aggressive JavaScript minimizers. Understandability
eol-last Trailing newlines in non-empty files are a common UNIX idiom. Benefits of trailing newlines include the ability to concatenate or append to files as well as output files to the terminal without interfering with shell prompts. Maintainability
eqeqeq It is considered good practice to use the type-safe equality operators === and !== instead of their regular counterparts == and !=. The reason for this is that == and != do type coercion which follows the rather obscure Abstract Equality Comparison Algorithm.
For instance, the following statements are all considered true:

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.

func-call-spacing When calling a function, developers may insert optional whitespace between the function’s name and the parentheses that invoke it. Understandability
func-name-matching This rule requires function names to match the name of the variable or property to which they are assigned. The rule will ignore property assignments where the property name is a literal that is not a valid identifier in the ECMAScript version specified in your configuration (default ES5). Understandability
func-names A pattern that’s becoming more common is to give function expressions names to aid in debugging. = 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.

func-style There are two ways of defining functions in JavaScript: function declarations and function expressions. Declarations contain the function keyword first, followed by a name and then its arguments and the function body/

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.

function-paren-newline Many style guides require or disallow newlines inside of function parentheses. Understandability
generator-star-spacing Generators are a new type of function in ECMAScript 6 that can return multiple values over time. These special functions are indicated by placing an * after the function keyword. To keep a sense of consistency when using generators this rule enforces a single position for the *. Maintainability
global-require In Node.js, module dependencies are included using the require() function, such as:

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.

guard-for-in Looping over objects with a for in loop will include properties that are inherited through the prototype chain. This behavior can lead to unexpected items in your for loop. Note that simply checking foo.hasOwnProperty(key) is likely to cause an error in some cases; see no-prototype-builtins. Maintainability
handle-callback-err In Node.js, a common pattern for dealing with asynchronous behavior is called the callback pattern. This pattern expects an Error object or null as the first argument of the callback. Forgetting to handle these errors can lead to some really strange behavior in your application. Robustness
id-blacklist Bad names can lead to hard-to-decipher code. Generic names, such as data, don’t infer much about the code and the values it receives. This rule allows you to configure a blacklist of bad identifier names, that you don’t want to see in your code. Maintainability
id-length Very short identifier names like e, x, _t or very long ones like hashGeneratorResultOutputContainerObject can make code harder to read and potentially less maintainable. To prevent this, one may enforce a minimum and/or maximum identifier length. Understandability
id-match Naming things consistently in a project is an often underestimated aspect of code creation. When done correctly, it can save your team hours of unnecessary head scratching and misdirections. This rule allows you to precisely define and enforce the variables and function names on your team should use. No more limiting yourself to camelCase, snake_case, PascalCase or oHungarianNotation. Id-match has all your needs covered! Understandability
implicit-arrow-linebreak An arrow function body can contain an implicit return as an expression instead of a block body. It can be useful to enforce a consistent location for the implicitly returned expression. Understandability
indent There are several common guidelines which require specific indentation of nested blocks and statements.

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

indent-legacy ESLint 4.0.0 introduced a rewrite of the indent rule, which now reports more errors than it did in previous versions. To ease the process of migrating to 4.0.0, the indent-legacy rule was introduced as a snapshot of the indent rule from ESLint 3.x. If your build is failing after the upgrade to 4.0.0, you can disable indent and enable indent-legacy as a quick fix. Eventually, you should switch back to the indent rule to get bugfixes and improvements in future versions. Understandability
init-declarations In JavaScript, variables can be assigned during declaration, or at any point afterwards using an assignment statement. For example, in the following code, foo is initialized during declaration, while bar is initialized later. Maintainability
jsx-quotes JSX attribute values can contain string literals, which are delimited with single or double quotes.


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.


key-spacing This rule enforces spacing around the colon in object literal properties. It can verify each property individually, or it can ensure horizontal alignment of adjacent properties in an object literal. Understandability
keyword-spacing Keywords are syntax elements of JavaScript, such as function and if. These identifiers have special meaning to the language and so often appear in a different color in code editors. As an important part of the language, style guides often refer to the spacing that should be used around keywords. For example, you might have a style guide that says keywords should be always surrounded by spaces, which would mean if-else statements must look like this:

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

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

line-comment-position Line comments can be positioned above or beside code. This rule helps teams maintain a consistent style.

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

linebreak-style When developing with a lot of people all having different editors, VCS applications and operating systems it may occur that different line endings are written by either of the mentioned (might especially happen when using the windows and mac versions of SourceTree together).

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.

lines-around-comment Many style guides require empty lines before or after comments. The primary goal of these rules is to make the comments easier to read and improve readability of the code. Understandability
lines-around-directive Directives are used in JavaScript to indicate to the execution environment that a script would like to opt into a feature such as “strict mode”. Directives are grouped together in a directive prologue at the top of either a file or function block and are applied to the scope in which they occur. Maintainability
lines-between-class-members This rule improves readability by enforcing lines between class members. It will not check empty lines before the first member and after the last member, since that is already taken care of by padded-blocks. Understandability
max-depth Many developers consider code difficult to read if blocks are nested beyond a certain depth. Understandability
max-len Very long lines of code in any language can be difficult to read. In order to aid in readability and maintainability many coders have developed a convention to limit lines of code to X number of characters (traditionally 80 characters). Understandability
max-nested-callbacks Many JavaScript libraries use the callback pattern to manage asynchronous operations. A program of any complexity will most likely need to manage several asynchronous operations at various levels of concurrency. A common pitfall that is easy to fall into is nesting callbacks, which makes code more difficult to read the deeper the callbacks are nested. Understandability
max-params Functions that take numerous parameters can be difficult to read and write because it requires the memorization of what each parameter is, its type, and the order they should appear in. As a result, many coders adhere to a convention that caps the number of parameters a function can take. Understandability
max-statements The max-statements rule allows you to specify the maximum number of statements allowed in a function. Understandability
max-statements-per-line A line of code containing too many statements can be difficult to read. Code is generally read from the top down, especially when scanning, so limiting the number of statements allowed on a single line can be very beneficial for readability and maintainability. Understandability
multiline-comment-style Many style guides require a particular style for comments that span multiple lines. For example, some style guides prefer the use of a single block comment for multiline comments, whereas other style guides prefer consecutive line comments. Understandability
multiline-ternary undefinedJavaScript allows operands of ternary expressions to be separated by newlines, which can improve the readability of your program. Understandability
new-cap The new operator in JavaScript creates a new instance of a particular type of object. That type of object is represented by a constructor function. Since constructor functions are just regular functions, the only defining characteristic is that new is being used as part of the call. Native JavaScript functions begin with an uppercase letter to distinguish those functions that are to be used as constructors from functions that are not. Many style guides recommend following this pattern to more easily determine which functions are to be used as constructors. Maintainability
new-parens JavaScript allows the omission of parentheses when invoking a function via the new keyword and the constructor has no arguments. However, some coders believe that omitting the parentheses is inconsistent with the rest of the language and thus makes code less clear. Maintainability
newline-after-var As of today there is no consistency in separating variable declarations from the rest of the code. Some developers leave an empty line between var statements and the rest of the code. Maintainability
newline-before-return There is no hard and fast rule about whether empty lines should precede return statements in JavaScript. However, clearly delineating where a function is returning can greatly increase the readability and clarity of the code. Maintainability
newline-per-chained-call Chained method calls on a single line without line breaks are harder to read, so some developers place a newline character after each method call in the chain to make it more readable and easy to maintain. Understandability
no-alert JavaScript’s alert, confirm, and prompt functions are widely considered to be obtrusive as UI elements and should be replaced by a more appropriate custom UI implementation. Furthermore, alert is often used while debugging code, which should be removed before deployment to production. Maintainability
no-array-constructor Use of the Array constructor to construct a new array is generally
discouraged in favor of array literal notation because of the single-argument
pitfall and because the Array global may be redefined. The exception is when
the Array constructor is used to intentionally create sparse arrays of a
specified size by giving the constructor a single numeric argument.
no-bitwise The use of bitwise operators in JavaScript is very rare and often & or | is simply a mistyped && or ||, which will lead to unexpected behavior.

var x = y | z;

no-buffer-constructor In Node.js, the behavior of the Buffer constructor is different depending on the type of its argument. Passing an argument from user input to Buffer() without validating its type can lead to security vulnerabilities such as remote memory disclosure and denial of service. As a result, the Buffer constructor has been deprecated and should not be used. Use the producer methods Buffer.from, Buffer.alloc, and Buffer.allocUnsafe instead. Maintainability
no-caller The use of arguments.caller and arguments.callee make several code optimizations impossible. They have been deprecated in future versions of JavaScript and their use is forbidden in ECMAScript 5 while in strict mode.

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

no-case-declarations This rule disallows lexical declarations (let, const, function and class)
in case/default clauses. The reason is that the lexical declaration is visible
in the entire switch block but it only gets initialized when it is assigned, which
will only happen if the case where it is defined is reached.

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

no-catch-shadow In IE 8 and earlier, the catch clause parameter can overwrite the value of a variable in the outer scope, if that variable has the same name as the catch clause parameter. Maintainability
no-confusing-arrow Arrow functions (=>) are similar in syntax to some comparison operators (>, <, <=, and >=). This rule warns against using the arrow function syntax in places where it could be confused with a comparison operator. Even if the arguments of the arrow function are wrapped with parens, this rule still warns about it unless allowParens is set to true. Understandability
no-console In JavaScript that is designed to be executed in the browser, it’s considered a best practice to avoid using methods on console. Such messages are considered to be for debugging purposes and therefore not suitable to ship to the client. In general, calls using console should be stripped before being pushed to production. Maintainability
no-continue The continue statement terminates execution of the statements in the current iteration of the current or labeled loop, and continues execution of the loop with the next iteration. When used incorrectly it makes code less testable, less readable and less maintainable. Structured control flow statements such as if should be used instead. Maintainability
no-duplicate-imports Using a single import statement per module will make the code clearer because you can see everything being imported from that module on one line. In the following example the module import on line 1 is repeated on line 3. These can be combined to make the list of imports more succinct.

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

no-else-return If an if block contains a return statement, the else block becomes unnecessary. Its contents can be placed outside of the block. Maintainability
no-empty Empty block statements, while not technically errors, usually occur due to refactoring that wasn’t completed. They can cause confusion when reading code. Maintainability
no-empty-function Empty functions can reduce readability because readers need to guess whether it’s intentional or not. So writing a clear comment for empty functions is a good practice.

function foo() {
// do nothing.

Especially, the empty block of arrow functions might be confusing developers.
It’s very similar to an empty object literal. => {}); // This is a block, would return undefined. => ({})); // This is an empty object.

no-eq-null Comparing to null without a type-checking operator (== or !=), can have unintended results as the comparison will evaluate to true when comparing to not just a null, but also an undefined value. Maintainability
no-extend-native In JavaScript, you can extend any object, including builtin or “native” objects. Sometimes people change the behavior of these native objects in ways that break the assumptions made about them in other parts of the code. Maintainability
no-extra-bind The bind() method is used to create functions with specific this values and, optionally, binds arguments to specific values. When used to specify the value of this, it’s important that the function actually use this in its function body. Sometimes during the course of code maintenance, the this value is removed from the function body. In that case, you can end up with a call to bind() that doesn’t accomplish anything. Maintainability
no-extra-label If a loop contains no nested loops or switches, labeling the loop is unnecessary. You can achieve the same result by removing the label and using break or continue without a label. Probably those labels would confuse developers because they expect labels to jump to further. Maintainability
no-extra-parens This rule restricts the use of parentheses to only where they are necessary. Maintainability
no-extra-semi Typing mistakes and misunderstandings about where semicolons are required can lead to semicolons that are unnecessary. While not technically an error, extra semicolons can cause confusion when reading code. Maintainability
no-floating-decimal Float values in JavaScript contain a decimal point, and there is no requirement that the decimal point be preceded or followed by a number. Although not a syntax error, this format for numbers can make it difficult to distinguish between true decimal numbers and the dot operator. For this reason, some recommend that you should always include a number before and after a decimal point to make it clear the intent is to create a decimal number. Maintainability
no-implicit-coercion In JavaScript, there are a lot of different ways to convert value types.
Some of them might be hard to read and understand.
no-implicit-globals When working with browser scripts, developers often forget that variable and function declarations at the top-level scope become global variables on the window object. As opposed to modules which have their own scope. Globals should be explicitly assigned to window or self if that is the intent. Otherwise variables intended to be local to the script should be wrapped in an IIFE. Maintainability
no-implied-eval It’s considered a good practice to avoid using eval() in JavaScript. There are security and performance implications involved with doing so, which is why many linters (including ESLint) recommend disallowing eval(). However, there are some other ways to pass a string and have it interpreted as JavaScript code that have similar concerns.

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() {
}, 100);”

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

no-inline-comments Some style guides disallow comments on the same line as code. Code can become difficult to read if comments immediately follow the code on the same line. On the other hand, it is sometimes faster and more obvious to put comments immediately following code. Understandability
no-inner-declarations In JavaScript, prior to ES6, a function declaration is only allowed in the first level of a program or the body of another function, though parsers sometimes erroneously accept them elsewhere. This only applies to function declarations; named or anonymous function expressions can occur anywhere an expression is permitted. Maintainability
no-invalid-this Under the strict mode, this keywords outside of classes or class-like objects might be undefined and raise a TypeError. Maintainability
no-iterator The __iterator__ property was a SpiderMonkey extension to JavaScript that could be used to create custom iterators that are compatible with JavaScript’s for in and for each constructs. However, this property is now obsolete, so it should not be used. You should use ECMAScript 6 iterators and generators instead. Maintainability
no-label-var This rule aims to create clearer code by disallowing the bad practice of creating a label that shares a name with a variable that is in scope. Maintainability
no-lone-blocks In JavaScript, prior to ES6, standalone code blocks delimited by curly braces do not create a new scope and have no use. In ES6, code blocks may create a new scope if a block-level binding (let and const), a class declaration or a function declaration (in strict mode) are present. A block is not considered redundant in these cases. Maintainability
no-lonely-if If an if statement is the only statement in the else block, it is often clearer to use an else if form. Maintainability
no-magic-numbers Magic numbers’ are numbers that occur multiple time in code without an explicit meaning. They should preferably be replaced by named constants. Maintainability
no-mixed-operators Enclosing complex expressions by parentheses clarifies the developer’s intention, which makes the code more readable. This rule warns when different operators are used consecutively without parentheses in an expression.

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.

no-mixed-spaces-and-tabs Most code conventions require either tabs or spaces be used for indentation. As such, it’s usually an error if a single line of code is indented with both tabs and spaces. Understandability
no-multi-assign Chaining the assignment of variables can lead to unexpected results and be difficult to read. Maintainability
no-multi-spaces Multiple spaces in a row that are not used for indentation are typically mistakes. Multiple spaces such as this are generally frowned upon in favor of single spaces. Maintainability
no-multi-str It’s possible to create multiline strings in JavaScript by using a slash before a newline. Some consider this to be a bad practice as it was an undocumented feature of JavaScript that was only formalized later. Understandability
no-multiple-empty-lines Some developers prefer to have multiple blank lines removed, while others feel that it helps improve readability. Whitespace is useful for separating logical sections of code, but excess whitespace takes up more of the screen. Understandability
no-negated-condition Negated conditions are more difficult to understand. Code can be made more readable by inverting the condition instead.

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

no-negated-in-lhs Negated conditions are more difficult to understand. Code can be made more readable by inverting the condition instead. Maintainability
no-nested-ternary Nesting ternary expressions can make code more difficult to understand. Maintainability
no-new The goal of using new with a constructor is typically to create an object of a particular type and store that object in a variable. Maintainability
no-new-func It’s possible to create functions in JavaScript using the Function constructor This is considered by many to be a bad practice due to the difficulty in debugging and reading these types of functions. Maintainability
no-new-object The Object constructor is used to create new generic objects in JavaScript. Many prefer to always use the object literal syntax and never use the Object constructor.

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.

no-new-require The require function is used to include modules that exist in separate files, such as:
var appHeader = require(‘app-header’);

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.

no-new-wrappers There are three primitive types in JavaScript that have wrapper objects: string, number, and boolean. These are represented by the constructors String, Number, and Boolean, respectively. The primitive wrapper types are used whenever one of these primitive values is read, providing them with object-like capabilities such as methods. Behind the scenes, an object of the associated wrapper type is created and then destroyed, which is why you can call methods on primitive values.

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.

no-octal Octal literals are numerals that begin with a leading zero. Because the leading zero which identifies an octal literal has been a source of confusion and error in JavaScript code, ECMAScript 5 deprecates the use of octal numeric literals. Maintainability
no-octal-escape As of the ECMAScript 5 specification, octal escape sequences in string literals are deprecated and should not be used. Unicode escape sequences should be used instead. Maintainability
no-param-reassign Assignment to variables declared as function parameters can be misleading and lead to confusing behavior, as modifying function parameters will also mutate the arguments object. Often, assignment to function parameters is unintended and indicative of a mistake or programmer error.

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.

no-path-concat In Node.js, the __dirname and __filename global variables contain the directory path and the file path of the currently executing script file, respectively. Sometimes, developers try to use these variables to create paths to other files. However, there are a few problems with this. First, you can’t be sure what type of system the script is running on. Node.js can be run on any computer, including Windows, which uses a different path separator. It’s very easy, therefore, to create an invalid path using string concatenation and assuming Unix-style separators. There’s also the possibility of having double separators, or otherwise ending up with an invalid path.

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.

no-proto __proto__ property has been deprecated as of ECMAScript 3.1 and shouldn’t be used in the code. Use getPrototypeOf method instead. Maintainability
no-restricted-globals Disallowing usage of specific global variables can be useful if you want to allow a set of global variables by enabling an environment, but still want to disallow some of those. For instance, early Internet Explorer versions exposed the current DOM event as a global variable event, but using this variable has been considered as a bad practice for a long time. Restricting this will make sure this variable isn’t used in browser code. Maintainability
no-restricted-imports Imports are an ES6/ES2015 standard for making the functionality of other modules available in your current module. In CommonJS this is implemented through the require() call which makes this ESLint rule roughly equivalent to its CommonJS counterpart no-restricted-modules.

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.

no-restricted-modules A module in Node.js is a simple or complex functionality organized in a JavaScript file which can be reused throughout the Node.js
application. The keyword require is used in Node.js/CommonJS to import modules into an application. This way you can have dynamic loading where the loaded module name isn’t predefined /static, or where you conditionally load a module only if it’s “truly required”.

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.

no-restricted-properties Certain properties on objects may be disallowed in a codebase. This is useful for deprecating an API or restricting usage of a module’s methods. For example, you may want to disallow using describe.only when using Mocha or telling people to use Object.assign instead of _.extend. Maintainability
no-restricted-syntax JavaScript has a lot of language features, and not everyone likes all of them. As a result, some projects choose to disallow the use of certain language features altogether. For instance, you might decide to disallow the use of try-catch or class, or you might decide to disallow the use of the in operator.

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.

no-return-assign One of the interesting, and sometimes confusing, aspects of JavaScript is that assignment can happen at almost any point. Because of this, an errant equals sign can end up causing assignment when the true intent was to do a comparison. This is especially true when using a return statement. Understandability
no-return-await Inside an async function, return await is useless. Since the return value of an async function is always wrapped in Promise.resolve, return await doesn’t actually do anything except add extra time before the overarching Promise resolves or rejects. This pattern is almost certainly due to programmer ignorance of the return semantics of async functions. Maintainability
no-script-url Using javascript: URLs is considered by some as a form of eval. Code passed in javascript: URLs has to be parsed and evaluated by the browser in the same way that eval is processed. Maintainability
no-self-compare Comparing a variable against itself is usually an error, either a typo or refactoring error. It is confusing to the reader and may potentially introduce a runtime error.

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.

no-spaced-func It’s possible to have whitespace between the name of a function and the parentheses that execute it, such patterns tend to look more like errors. Maintainability
no-sync In Node.js, most I/O is done through asynchronous methods. However, there are often synchronous versions of the asynchronous methods. For example, fs.exists() and fs.existsSync(). In some contexts, using synchronous operations is okay (if, as with ESLint, you are writing a command line utility). However, in other contexts the use of synchronous operations is considered a bad practice that should be avoided. For example, if you are running a high-travel web server on Node.js, you should consider carefully if you want to allow any synchronous operations that could lock up the server. Maintainability
no-tabs Some style guides don’t allow the use of tab characters at all, including within comments. Maintainability
no-template-curly-in-string ECMAScript 6 allows programmers to create strings containing variable or expressions using template literals, instead of string concatenation, by writing expressions like ${variable} between two backtick quotes (`). It can be easy to use the wrong quotes when wanting to use template literals, by writing “${variable}”, and end up with the literal value “${variable}” instead of a string containing the value of the injected expressions. Maintainability
no-ternary The ternary operator is used to conditionally assign a value to a variable. Some believe that the use of ternary operators leads to unclear code. Maintainability
no-throw-literal It is considered good practice to only throw the Error object itself or an object using the Error object as base objects for user-defined exceptions.
The fundamental benefit of Error objects is that they automatically keep track of where they were built and originated.

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.

no-trailing-spaces Sometimes in the course of editing files, you can end up with extra whitespace at the end of lines. These whitespace differences can be picked up by source control systems and flagged as diffs, causing frustration for developers. While this extra whitespace causes no functional issues, many code conventions require that trailing spaces be removed before check-in. Maintainability
no-undefined In JavaScript, a variable that is declared and not initialized to any value automatically gets the value of undefined. Maintainability
no-underscore-dangle As far as naming conventions for identifiers go, dangling underscores may be the most polarizing in JavaScript. Dangling underscores are underscores at either the beginning or end of an identifier.

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.

no-unneeded-ternary It’s a common mistake in JavaScript to use a conditional expression to select between two Boolean values instead of using ! to convert the test to a Boolean.

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.

no-unsafe-negation Just as developers might type -a + b when they mean -(a + b) for the negative of a sum, they might type !key in object by mistake when they almost certainly mean !(key in object) to test that a key is not in an object. !obj instanceof Ctor is similar. Maintainability
no-unused-expressions An unused expression which has no effect on the state of the program indicates a logic error.

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.

no-unused-vars Variables that are declared and not used anywhere in the code are most likely an error due to incomplete refactoring. Such variables take up space in the code and can lead to confusion by readers. Maintainability
no-use-before-define In JavaScript, prior to ES6, variable and function declarations are hoisted to the top of a scope, so it’s possible to use identifiers before their formal declarations in code. This can be confusing and some believe it is best to always declare variables and functions before using them.

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.

no-useless-call The function invocation can be written by and Function.prototype.apply().

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

no-useless-computed-key It’s unnecessary to use computed properties with literals such as: var foo = {[“a”]: “b”}; Maintainability
no-useless-concat It’s unnecessary to concatenate two strings together, such as:
var foo = “a” + “b”;

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”;

no-useless-constructor ES2015 provides a default class constructor if one is not specified. As such, it is unnecessary to provide an empty constructor or one that simply delegates into its parent class. Maintainability
no-useless-rename ES2015 allows for the renaming of references in import and export statements as well as destructuring assignments. This gives programmers a concise syntax for performing these operations while renaming these references. Maintainability
no-useless-return A return; statement with nothing after it is redundant, and has no effect on the runtime behavior of a function. This can be confusing, so it’s better to disallow these redundant statements. Maintainability
no-var ECMAScript 6 allows programmers to create variables with block scope instead of function scope using the let and const keywords. Block scope is common in many other programming languages and helps programmers avoid mistakes. Maintainability
no-void The void operator takes an operand and returns undefined: void expression will evaluate expression and return undefined. It can be used to ignore any side effects expression may produce. Maintainability
no-warning-comments Developers often add comments to code which is not complete or needs review. Most likely you want to fix or review the code, and then remove the comment, before you consider the code to be production ready. Understandability
no-whitespace-before-property JavaScript allows whitespace between objects and their properties. However, inconsistent spacing can make code harder to read and can lead to errors. Maintainability
no-with The with statement is potentially problematic because it adds members of an object to the current scope, making it impossible to tell what a variable inside the block actually refers to. Maintainability
nonblock-statement-body-position When writing if, else, while, do-while, and for statements, the body can be a single statement instead of a block. It can be useful to enforce a consistent location for these single statements. Maintainability
object-curly-newline A number of style guides require or disallow line breaks inside of object braces and other tokens. Understandability
object-curly-spacing While formatting preferences are very personal, a number of style guides require or disallow spaces between curly braces in the following situations. Understandability
object-property-newline This rule permits you to restrict the locations of property specifications in object literals. You may prohibit any part of any property specification from appearing on the same line as any part of any other property specification. You may make this prohibition absolute, or, by invoking an object option, you may allow an exception, permitting an object literal to have all parts of all of its property specifications on a single line. Maintainability
object-shorthand ECMAScript 6 provides a concise form for defining object literal methods and properties. This syntax can make defining complex object literals much cleaner. Maintainability
one-var Variables can be declared at any point in JavaScript code using var, let, or const. There are many styles and preferences related to the declaration of variables, and one of those is deciding on how many variable declarations should be allowed in a single function.

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.

one-var-declaration-per-line Some developers declare multiple var statements on the same line, others prefer to declare one var per line. Keeping to one of these styles across a project’s codebase can help with maintaining code consistency. Maintainability
operator-assignment JavaScript provides shorthand operators that combine variable assignment and some simple mathematical operations. For example, x = x + 4 can be shortened to x += 4. Maintainability
operator-linebreak When a statement is too long to fit on a single line, line breaks are generally inserted next to the operators separating expressions. Maintainability
padded-blocks Some style guides require block statements to start and end with blank lines. The goal is to improve readability by visually separating the block content and the surrounding code. Since it’s good to have a consistent code style, you should either always write padded blocks or never do it. Maintainability
padding-line-between-statements This rule requires or disallows blank lines between the given 2 kinds of statements. Properly blank lines help developers to understand the code. Maintainability
prefer-arrow-callback Arrow functions can be an attractive alternative to function expressions for callbacks or function arguments.

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.

prefer-const If a variable is never reassigned, using the const declaration is better.

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

prefer-destructuring With JavaScript ES6, a new syntax was added for creating variables from an array index or object property, called destructuring. This rule enforces usage of destructuring instead of accessing a property through a member expression. Maintainability
prefer-numeric-literals The parseInt() and Number.parseInt() functions can be used to turn binary, octal, and hexadecimal strings into integers. As binary, octal, and hexadecimal literals are supported in ES6, this rule encourages use of those numeric literals instead of parseInt() or Number.parseInt(). Maintainability
prefer-promise-reject-errors It is considered good practice to only pass instances of the built-in Error object to the reject() function for user-defined errors in Promises. Error objects automatically store a stack trace, which can be used to debug an error by determining where it came from. If a Promise is rejected with a non-Error value, it can be difficult to determine where the rejection occurred. Maintainability
prefer-reflect This rule was deprecated in ESLint v3.9.0 and will not be replaced. The original intent of this rule now seems misguided as we have come to understand that Reflect methods are not actually intended to replace the Object counterparts the rule suggests, but rather exist as low-level primitives to be used with proxies in order to replicate the default behavior of various previously existing functionality. Maintainability
prefer-rest-params There are rest parameters in ES2015.
We can use that feature for variadic functions instead of the arguments variable.

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

prefer-spread Before ES2015, one must use Function.prototype.apply() to call variadic functions. In ES2015, one can use the spread operator to call variadic functions. Maintainability
prefer-template In ES2015 (ES6), we can use template literals instead of string concatenation. Maintainability
quote-props Object literal property names can be defined in two ways: using literals or using strings. In many cases, it doesn’t matter if you choose to use an identifier instead of a string or vice-versa. Even so, you might decide to enforce a consistent style in your code.

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”.

quotes JavaScript allows you to define strings in one of three ways: double quotes, single quotes, and backticks (as of ECMAScript 6). Each of these lines creates a string and, in some cases, can be used interchangeably. The choice of how to define strings in a codebase is a stylistic one outside of template literals (which allow embedded of expressions to be interpreted). Many codebases require strings to be defined in a consistent manner. Maintainability
radix When using the parseInt() function it is common to omit the second argument, the radix, and let the function try to determine from the first argument what type of number it is. By default, parseInt() will autodetect decimal and hexadecimal (via 0x prefix). Prior to ECMAScript 5, parseInt() also autodetected octal literals, which caused problems because many developers assumed a leading 0 would be ignored.

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.

require-await Async functions which have no await expression may be the unintentional result of refactoring. Maintainability
require-jsdoc JSDoc is a JavaScript API documentation generator. It uses specially-formatted comments inside of code to generate API documentation automatically. Some style guides require JSDoc comments for all functions as a way of explaining function behavior. Understandability
rest-spread-spacing ES2015 introduced the rest and spread operators, which expand an iterable structure into its individual parts. There is currently a proposal to add object rest and spread properties to the spec. As with other operators, whitespace is allowed between the rest or spread operator and the expression it is operating on, which can lead to inconsistent spacing within a codebase. Maintainability
semi JavaScript is unique amongst the C-like languages in that it doesn’t require semicolons at the end of each statement. In many cases, the JavaScript engine can determine that a semicolon should be in a certain spot and will automatically add it. This feature is known as automatic semicolon insertion (ASI) and is considered one of the more controversial features of JavaScript.

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.

semi-spacing JavaScript allows you to place unnecessary spaces before or after a semicolon.

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

semi-style Generally, semicolons are at the end of lines. However, in semicolon-less style, semicolons are at the beginning of lines. This rule enforces that semicolons are at the configured location. Maintainability
sort-imports The import statement is used to import members (functions, objects or primitives) that have been exported from an external module. Using a specific member syntax. The import statement can also import a module without exported bindings. Used when the module does not export anything, but runs it own code or changes the global context object. When declaring multiple imports, a sorted list of import declarations make it easier for developers to read the code and find necessary imports later. This rule is purely a matter of style. Understandability
sort-keys When declaring multiple properties, some developers prefer to sort property names alphabetically to be able to find necessary property easier at the later time. Others feel that it adds complexity and becomes burden to maintain. Understandability
sort-vars When declaring multiple variables within the same block, some developers prefer to sort variable names alphabetically to be able to find necessary variable easier at the later time. Others feel that it adds complexity and becomes burden to maintain. Understandability
space-before-blocks Consistency is an important part of any style guide.
While it is a personal preference where to put the opening brace of blocks, it should be consistent across a whole project. Having an inconsistent style distracts the reader from seeing the important parts of the code.
space-before-function-paren When formatting a function, whitespace is allowed between the function name or function keyword and the opening paren. Named functions also require a space between the function keyword and the function name, but anonymous functions require no whitespace. Style guides may require a space after the function keyword for anonymous functions, while others specify no whitespace. Similarly, the space after a function name may or may not be required. Understandability
space-in-parens Some style guides require or disallow a whitespace immediately after the initial // or /* of a comment. Whitespace after the // or /* makes it easier to read text in comments. On the other hand, commenting out code is easier without having to put a whitespace right after the // or /*. Maintainability
space-infix-ops While formatting preferences are very personal, a number of style guides require spaces around operators. The proponents of these extra spaces believe it make the code easier to read and can more easily highlight potential errors. Understandability
space-unary-ops Some style guides require or disallow spaces inside of parentheses. Understandability
spaced-comment Some style guides require or disallow spaces before or after unary operators. This is mainly a stylistic issue, however, some JavaScript expressions can be written without spacing which makes it harder to read and maintain. Understandability
switch-colon-spacing Spacing around colons improves readability of case/default clauses. Maintainability
symbol-description The Symbol function may have optional description. Using description promotes easier debugging: when a symbol is logged the description is used. It may facilitate identifying symbols when one is observed during debugging. Maintainability
template-curly-spacing We can embed expressions in template strings with using a pair of ${ and }. This rule can force usage of spacing within the curly brace pair according to style guides. Maintainability
template-tag-spacing With ES6, it’s possible to create functions called tagged template literals where the function parameters consist of a template literal’s strings and expressions. When using tagged template literals, it’s possible to insert whitespace between the tag function and the template literal. Maintainability
unicode-bom The Unicode Byte Order Mark (BOM) is used to specify whether code units are big endian or little endian. That is, whether the most significant or least significant bytes come first. UTF-8 does not require a BOM because byte ordering does not matter when characters are a single byte. Since UTF-8 is the dominant encoding of the web, we make “never” the default option. Maintainability
valid-jsdoc JSDoc generates application programming interface (API) documentation from specially-formatted comments in JavaScript code. If comments are invalid because of typing mistakes, then documentation will be incomplete. If comments are inconsistent because they are not updated when function definitions are modified, then readers might become confused. Maintainability
vars-on-top The vars-on-top rule generates warnings when variable declarations are not used serially at the top of a function scope or the top of a program. By default variable declarations are always moved (“hoisted”) invisibly to the top of their containing scope by the JavaScript interpreter.
This rule forces the programmer to represent that behavior by manually moving the variable declaration to the top of its containing scope.
wrap-iife You can immediately invoke function expressions, but not function declarations. A common technique to create an immediately-invoked function expression (IIFE) is to wrap a function declaration in parentheses. The opening parentheses causes the contained function to be parsed as an expression, rather than a declaration. Maintainability
wrap-regex When a regular expression is used in certain situations, it can end up looking like a division operator. Maintainability
yield-star-spacing This rule enforces spacing around the * in yield* expressions. Maintainability
yoda Yoda conditions are so named because the literal value of the condition comes first while the variable comes second. For example, the following is a Yoda condition:

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.