Rule | Description | KPI | URL |
---|---|---|---|
block-scoped-var | The block-scoped-var rule generates warnings when variables are used outside of the block in which they were defined. This emulates C-style block scope. | Analyzability | https://eslint.org/docs/rules/block-scoped-var |
callback-return | The callback pattern is at the heart of most I/O and event-driven programming in JavaScript. To prevent calling the callback multiple times it is important to return anytime the callback is triggered outside of the main function body. Neglecting this technique often leads to issues where you do something more than once. For example, in the case of an HTTP request, you may try to send HTTP headers more than once leading Node.js to throw a Can’t render headers after they are sent to the client. error. | Accuracy | https://eslint.org/docs/rules/callback-return |
default-case | Some code conventions require that all switch statements have a default case, even if the default case is empty. The thinking is that it’s better to always explicitly state what the default behavior should be so that it’s clear whether or not the developer forgot to include the default behavior by mistake. Other code conventions allow you to skip the default case so long as there is a comment indicating the omission is intentional. Once again, the intent here is to show that the developer intended for there to be no default behavior. | Robustness | https://eslint.org/docs/rules/default-case |
getter-return | The get syntax binds an object property to a function that will be called when that property is looked up. It was first introduced in ECMAScript 5. Note that every getter is expected to return a value. | Maintainability | https://eslint.org/docs/rules/getter-return |
max-lines | undefinedSome people consider large files a code smell. Large files tend to do a lot of things and can make it hard following what’s going. While there is not an objective maximum number of lines considered acceptable in a file, most people would agree it should not be in the thousands. Recommendations usually range from 100 to 500 lines. | Understandability | https://eslint.org/docs/rules/max-lines |
no-await-in-loop | Performing an operation on each element of an iterable is a common task. However, performing an await as part of each operation is an indication that the program is not taking full advantage of the parallelization benefits of async/await.
Usually, the code should be refactored to create all the promises at once, then get access to the results using Promise.all(). Otherwise, each successive operation will not start until the previous one has completed. |
Maintainability | https://eslint.org/docs/rules/no-await-in-loop |
no-class-assign | ClassDeclaration creates a variable, and we can modify the variable. But the modification is a mistake in most cases. | Maintainability | https://eslint.org/docs/rules/no-class-assign |
no-compare-neg-zero | The rule should warn against code that tries to compare against -0, since that will not work as intended. That is, code like x === -0 will pass for both +0 and -0. The author probably intended Object.is(x, -0). | Analyzability | https://eslint.org/docs/rules/no-compare-neg-zero |
no-cond-assign | In conditional statements, it is very easy to mistype a comparison operator (such as ==) as an assignment operator (such as =). mThere are valid reasons to use assignment operators in conditional statements. However, it can be difficult to tell whether a specific assignment was intentional. | Maintainability | https://eslint.org/docs/rules/no-cond-assign |
no-constant-condition | We cannot modify variables that are declared using const keyword. It will raise a runtime error. Under non ES2015 environment, it might be ignored merely. |
Maintainability | https://eslint.org/docs/rules/no-const-assign |
no-delete-var | The purpose of the delete operator is to remove a property from an object. Using the delete operator on a variable might lead to unexpected behavior. | Maintainability | https://eslint.org/docs/rules/no-delete-var |
no-div-regex | Require regex literals to escape division operators. | Maintainability | https://eslint.org/docs/rules/no-div-regex |
no-duplicate-case | If a switch statement has duplicate test expressions in case clauses, it is likely that a programmer copied a case clause but forgot to change the test expression. | Maintainability | https://eslint.org/docs/rules/no-duplicate-case |
no-empty-character-class | Because empty character classes in regular expressions do not match anything, they might be typing mistakes.
var foo = /^abc[]/; |
Maintainability | https://eslint.org/docs/rules/no-empty-character-class |
no-empty-pattern | When using destructuring, it’s possible to create a pattern that has no effect. This happens when empty curly braces are used to the right of an embedded object destructuring pattern. | Maintainability | https://eslint.org/docs/rules/no-empty-pattern |
no-eval | JavaScript’s eval() function is potentially dangerous and is often misused. Using eval() on untrusted code can open a program up to several different injection attacks. The use of eval() in most contexts can be substituted for a better, alternative approach to a problem. | Security | https://eslint.org/docs/rules/no-eval |
no-ex-assign | If a catch clause in a try statement accidentally (or purposely) assigns another value to the exception parameter, it impossible to refer to the error from that point on. Since there is no arguments object to offer alternative access to this data, assignment of the parameter is absolutely destructive. | Robustness | https://eslint.org/docs/rules/no-ex-assign |
no-extra-boolean-cast | In contexts such as an if statement’s test where the result of the expression will already be coerced to a Boolean, casting to a Boolean via double negation (!!) or a Boolean call is unnecessary. | Maintainability | https://eslint.org/docs/rules/no-extra-boolean-cast |
no-fallthrough | The switch statement in JavaScript is one of the more error-prone constructs of the language thanks in part to the ability to “fall through” from one case to the next. That works fine when you don’t want a fallthrough, but what if the fallthrough is intentional, there is no way to indicate that in the language. It’s considered a best practice to always indicate when a fallthrough is intentional using a comment which matches the //falls through regular expression. | Maintainability | https://eslint.org/docs/rules/no-fallthrough |
no-func-assign | JavaScript functions can be written as a FunctionDeclaration function foo() { … } or as a FunctionExpression var foo = function() { … };. While a JavaScript interpreter might tolerate it, overwriting/reassigning a function written as a FunctionDeclaration is often indicative of a mistake or issue. | Maintainability | https://eslint.org/docs/rules/no-func-assign |
no-invalid-regexp | An invalid pattern in a regular expression literal is a SyntaxError when the code is parsed, but an invalid string in RegExp constructors throws a SyntaxError only when the code is executed. | Maintainability | https://eslint.org/docs/rules/no-invalid-regexp |
no-irregular-whitespace | Invalid or irregular whitespace causes issues with ECMAScript 5 parsers and also makes code harder to debug in a similar nature to mixed tabs and spaces.
Various whitespace characters can be inputted by programmers by mistake for example from copying or keyboard shortcuts. Pressing Alt + Space on macOS adds in a non breaking space character for example. Known issues these spaces cause: |
Maintainability | https://eslint.org/docs/rules/no-irregular-whitespace |
no-labels | Labeled statements in JavaScript are used in conjunction with break and continue to control flow around multiple loops. While convenient in some cases, labels tend to be used only rarely and are frowned upon by some as a remedial form of flow control that is more error prone and harder to understand. | Maintainability | https://eslint.org/docs/rules/no-labels |
no-loop-func | Writing functions within loops tends to result in errors due to the way the function creates a closure around the loop. For example: | Maintainability | https://eslint.org/docs/rules/no-loop-func |
no-mixed-requires | In the Node.js community it is often customary to separate initializations with calls to require modules from other variable declarations, sometimes also grouping them by the type of module. This rule helps you enforce this convention. | Maintainability | https://eslint.org/docs/rules/no-mixed-requires |
no-native-reassign | JavaScript environments contain a number of built-in global variables, such as window in browsers and process in Node.js. In almost all cases, you don’t want to assign a value to these global variables as doing so could result in losing access to important functionality. For example, you probably don’t want to do this in browser code:
“window = {};” While examples such as window are obvious, there are often hundreds of built-in global objects provided by JavaScript environments. It can be hard to know if you’re assigning to a global variable or not. |
Maintainability | https://eslint.org/docs/rules/no-native-reassign |
no-new-symbol | Symbol is not intended to be used with the new operator, but to be called as a function. | Maintainability | https://eslint.org/docs/rules/no-new-symbol |
no-plusplus | Because the unary ++ and — operators are subject to automatic semicolon insertion, differences in whitespace can change semantics of source code.
// i = 11, j = 20 i ++ // i = 10, j = 21 i |
Robustness | https://eslint.org/docs/rules/no-plusplus |
no-process-exit | The process.exit() method in Node.js is used to immediately stop the Node.js process and exit. This is a dangerous operation because it can occur in any method at any point in time, potentially stopping a Node.js application completely when an error occurs.
If you are using process.exit() only for specifying the exit code, you can set process.exitCode (introduced in Node.js 0.11.8) instead. |
Robustness | https://eslint.org/docs/rules/no-process-exit |
no-prototype-builtins | In ECMAScript 5.1, Object.create was added, which enables the creation of objects with a specified [[Prototype]]. Object.create(null) is a common pattern used to create objects that will be used as a Map. This can lead to errors when it is assumed that objects will have properties from Object.prototype. This rule prevents calling Object.prototype methods directly from an object. | Maintainability | https://eslint.org/docs/rules/no-prototype-builtins |
no-redeclare | In JavaScript, it’s possible to redeclare the same variable name using var. This can lead to confusion as to where the variable is actually declared and initialized. | Maintainability | https://eslint.org/docs/rules/no-redeclare |
no-regex-spaces | Regular expressions can be very complex and difficult to understand, which is why it’s important to keep them as simple as possible in order to avoid mistakes. One of the more error-prone things you can do with a regular expression is to use more than one space. It’s better to use only one space and then specify how many spaces are expected. | Maintainability | https://eslint.org/docs/rules/no-regex-spaces |
no-self-assign | Self assignments have no effect, so probably those are an error due to incomplete refactoring. Those indicate that what you should do is still remaining. | Maintainability | https://eslint.org/docs/rules/no-self-assign |
no-sequences | The comma operator includes multiple expressions where only one is expected. It evaluates each operand from left to right and returns the value of the last operand. However, this frequently obscures side effects, and its use is often an accident. | Maintainability | https://eslint.org/docs/rules/no-sequences |
no-shadow | Shadowing is the process by which a local variable shares the same name as a variable in its containing scope. | Maintainability | https://eslint.org/docs/rules/no-shadow |
no-shadow-restricted-names | ES5 §15.1.1 Value Properties of the Global Object (NaN, Infinity, undefined) as well as strict mode restricted identifiers eval and arguments are considered to be restricted names in JavaScript. Defining them to mean something else can have unintended consequences and confuse others reading the code. | Maintainability | https://eslint.org/docs/rules/no-shadow-restricted-names |
no-sparse-arrays | Sparse arrays contain empty slots, most frequently due to multiple commas being used in an array literal, such as:
var items = [,,]; While the items array in this example has a length of 2, there are actually no values in items[0] or items[1]. The fact that the array literal is valid with only commas inside, coupled with the length being set and actual item values not being set, make sparse arrays confusing for many developers. The confusion around sparse arrays defined in this manner is enough that it’s recommended to avoid using them unless you are certain that they are useful in your code. |
Maintainability | https://eslint.org/docs/rules/no-sparse-arrays |
no-this-before-super | In the constructor of derived classes, if this/super are used before super() calls, it raises a reference error. This rule checks this/super keywords in constructors, then reports those that are before super(). | Maintainability | https://eslint.org/docs/rules/no-this-before-super |
no-undef | This rule can help you locate potential ReferenceErrors resulting from misspellings of variable and parameter names, or accidental implicit globals (for example, from forgetting the var keyword in a for loop initializer). | Maintainability | https://eslint.org/docs/rules/no-undef |
no-undef-init | The undefined variable in JavaScript is actually a property of the global object. As such, in ECMAScript 3 it was possible to overwrite the value of undefined. While ECMAScript 5 disallows overwriting undefined, it’s still possible to shadow undefined. Because undefined can be overwritten or shadowed, reading undefined can give an unexpected value. (This is not the case for null, which is a keyword that always produces the same value.) To guard against this, you can avoid all uses of undefined, which is what some style guides recommend and what this rule enforces.
Those style guides then also recommend: As an alternative, you can use the no-global-assign and no-shadow-restricted-names rules to prevent undefined from being shadowed or assigned a different value. This ensures that undefined will always hold its original, expected value. |
Maintainability | https://eslint.org/docs/rules/no-undefined |
no-unexpected-multiline | Semicolons are usually optional in JavaScript, because of automatic semicolon insertion (ASI). You can require or disallow semicolons with the semi rule.
The rules for ASI are relatively straightforward: As once described by Isaac Schlueter, a newline character always ends a statement, just like a semicolon, except where one of the following is true: In the exceptions where a newline does not end a statement, a typing mistake to omit a semicolon causes two unrelated consecutive lines to be interpreted as one expression. Especially for a coding style without semicolons, readers might overlook the mistake. Although syntactically correct, the code might throw exceptions when it is executed. |
Maintainability | https://eslint.org/docs/rules/no-unexpected-multiline |
no-unmodified-loop-condition | Variables in a loop condition often are modified in the loop. If not, it’s possibly a mistake. |
Robustness | https://eslint.org/docs/rules/no-unmodified-loop-condition |
no-unsafe-finally | JavaScript suspends the control flow statements of try and catch blocks until the execution of finally block finishes. So, when return, throw, break, or continue is used in finally, control flow statements inside try and catch are overwritten, which is considered as unexpected behavior. | Maintainability | https://eslint.org/docs/rules/no-unsafe-finally |
no-unused-labels | Labels that are declared and not used anywhere in the code are most likely an error due to incomplete refactoring. Such labels take up space in the code and can lead to confusion by readers. | Maintainability | https://eslint.org/docs/rules/no-unused-labels |
no-useless-escape | Escaping non-special characters in strings, template literals, and regular expressions doesn’t have any effect. | Maintainability | https://eslint.org/docs/rules/no-useless-escape |
require-yield | This rule generates warnings for generator functions that do not have the yield keyword. | Maintainability | https://eslint.org/docs/rules/require-yield |
strict | A strict mode directive is a “use strict” literal at the beginning of a script or function body. It enables strict mode semantics.
When a directive occurs in global scope, strict mode applies to the entire script. When a directive occurs at the beginning of a function body, strict mode applies only to that function, including all contained functions. In the CommonJS module system, a hidden function wraps each module and limits the scope of a “global” strict mode directive. In ECMAScript modules, which always have strict mode semantics, the directives are unnecessary. |
Maintainability | https://eslint.org/docs/rules/strict |
use-isnan | In JavaScript, NaN is a special value of the Number type. It’s used to represent any of the “not-a-number” values represented by the double-precision 64-bit format as specified by the IEEE Standard for Binary Floating-Point Arithmetic.
Because NaN is unique in JavaScript by not being equal to anything, including itself, the results of comparisons to NaN are confusing. Therefore, use Number.isNaN() or global isNaN() functions to test whether a value is NaN. |
Maintainability | https://eslint.org/docs/rules/use-isnan |
valid-typeof | For a vast majority of use cases, the result of the typeof operator is one of the following string literals: “undefined”, “object”, “boolean”, “number”, “string”, “function” and “symbol”. It is usually a typing mistake to compare the result of a typeof operator to other string literals. | Maintainability | https://eslint.org/docs/rules/valid-typeof |