| Rule | Description | KPI | URL |
|---|---|---|---|
| constructor-super | Constructors of derived classes must call super(). Constructors of non derived classes must not call super(). If this is not observed, the JavaScript engine will raise a runtime error. This rule checks whether or not there is a valid super() call. | Robustness | https://eslint.org/docs/rules/constructor-super |
| for-direction | A for loop with a stop condition that can never be reached, such as one with a counter that moves in the wrong direction, will run infinitely. While there are occasions when an infinite loop is intended, the convention is to construct such loops as while loops. More typically, an infinite for loop is a bug. | Robustness | https://eslint.org/docs/rules/for-direction |
| no-const-assign | A constant expression (for example, a literal) as a test condition might be a typo or development trigger for a specific behavior. For example, the following code looks as if it is not ready for production. | Maintainability | https://eslint.org/docs/rules/no-constant-condition |
| no-control-regex | Control characters are special, invisible characters in the ASCII range 0-31. These characters are rarely used in JavaScript strings so a regular expression containing these characters is most likely a mistake. | Maintainability | https://eslint.org/docs/rules/no-control-regex |
| no-debugger | The debugger statement is used to tell the executing JavaScript environment to stop execution and start up a debugger at the current point in the code. This has fallen out of favor as a good practice with the advent of modern debugging and development tools. Production code should definitely not contain debugger, as it will cause the browser to stop executing code and open an appropriate debugger. | Maintainability | https://eslint.org/docs/rules/no-debugger |
| no-dupe-args | If more than one parameter has the same name in a function definition, the last occurrence “shadows” the preceding occurrences. A duplicated name might be a typing error. | Maintainability | https://eslint.org/docs/rules/no-dupe-args |
| no-dupe-class-members | If there are declarations of the same name in class members, the last declaration overwrites other declarations silently. It can cause unexpected behaviors. | Maintainability | https://eslint.org/docs/rules/no-dupe-class-members |
| no-dupe-keys | Multiple properties with the same key in object literals can cause unexpected behavior in your application. | Maintainability | https://eslint.org/docs/rules/no-dupe-keys |
| no-global-assign | 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. |
Robustness | https://eslint.org/docs/rules/no-global-assign |
| no-obj-calls | ECMAScript provides several global objects that are intended to be used as-is. Some of these objects look as if they could be constructors due their capitalization (such as Math and JSON) but will throw an error if you try to execute them as functions. | Maintainability | https://eslint.org/docs/rules/no-obj-calls |
| no-process-env | The process.env object in Node.js is used to store deployment/configuration parameters. Littering it through out a project could lead to maintenance issues as it’s another kind of global dependency. As such, it could lead to merge conflicts in a multi-user setup and deployment issues in a multi-server setup. Instead, one of the best practices is to define all those parameters in a single configuration/settings file which could be accessed throughout the project. | Robustness | https://eslint.org/docs/rules/no-process-env |
| no-unreachable | Because the return, throw, break, and continue statements unconditionally exit a block of code, any statements after them cannot be executed. Unreachable statements are usually a mistake. | Efficiency | https://eslint.org/docs/rules/no-unreachable |