Array.prototype.includes = function(searchElement /*, fromIndex*/ ) {
    'use strict';
    var O = Object(this);
    var len = parseInt(O.length) || 0;
    if (len === 0) {

Close

Cognitive Complexity

Cognitive Complexity is a measure of how difficult a unit of code is to intuitively understand. Unlike Cyclomatic Complexity, which determines how difficult your code will be to test, Cognitive Complexity tells you how difficult your code will be to read and comprehend.

A method's cognitive complexity is based on a few simple rules:

• Code is not considered more complex when it uses shorthand that the language provides for collapsing multiple statements into one
• Code is considered more complex for each "break in the linear flow of the code"
• Code is considered more complex when "flow breaking structures are nested"

Further reading

• Cognitive Complexity docs
• Cognitive Complexity: A new way of measuring understandability

  Array.prototype.includes = function(searchElement /*, fromIndex*/ ) {

Close

Requires or disallows a whitespace (space or tab) beginning a comment (spaced-comment)

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 /*.

Rule Details

This rule will enforce consistency of spacing after the start of a comment // or /*. It also provides several exceptions for various documentation styles.

Options

The rule takes two options.

• The first is a string which be either "always" or "never". The default is "always".

  • If "always" then the // or /* must be followed by at least one whitespace.
  • If "never" then there should be no whitespace following.

• This rule can also take a 2nd option, an object with any of the following keys: "exceptions" and "markers".

  • The "exceptions" value is an array of string patterns which are considered exceptions to the rule. Please note that exceptions are ignored if the first argument is "never".

  "spaced-comment": ["error", "always", { "exceptions": ["-", "+"] }]

  • The "markers" value is an array of string patterns which are considered markers for docblock-style comments, such as an additional /, used to denote documentation read by doxygen, vsdoc, etc. which must have additional characters. The "markers" array will apply regardless of the value of the first argument, e.g. "always" or "never".

  "spaced-comment": ["error", "always", { "markers": ["/"] }]

The difference between a marker and an exception is that a marker only appears at the beginning of the comment whereas exceptions can occur anywhere in the comment string.

You can also define separate exceptions and markers for block and line comments. The "block" object can have an additional key "balanced", a boolean that specifies if inline block comments should have balanced spacing. The default value is false.

• If "balanced": true and "always" then the /* must be followed by at least one whitespace, and the */ must be preceded by at least one whitespace.

• If "balanced": true and "never" then there should be no whitespace following /* or preceding */.

• If "balanced": false then balanced whitespace is not enforced.

"spaced-comment": ["error", "always", {
    "line": {
        "markers": ["/"],
        "exceptions": ["-", "+"]
    },
    "block": {
        "markers": ["!"],
        "exceptions": ["*"],
        "balanced": true
    }
}]

always

Examples of incorrect code for this rule with the "always" option:

/*eslint spaced-comment: ["error", "always"]*/

//This is a comment with no whitespace at the beginning

/*This is a comment with no whitespace at the beginning */

/* eslint spaced-comment: ["error", "always", { "block": { "balanced": true } }] */
/* This is a comment with whitespace at the beginning but not the end*/

Examples of correct code for this rule with the "always" option:

/* eslint spaced-comment: ["error", "always"] */

// This is a comment with a whitespace at the beginning

/* This is a comment with a whitespace at the beginning */

/*
 * This is a comment with a whitespace at the beginning
 */

/*
This comment has a newline
*/

/* eslint spaced-comment: ["error", "always"] */

/**
* I am jsdoc
*/

never

Examples of incorrect code for this rule with the "never" option:

/*eslint spaced-comment: ["error", "never"]*/

// This is a comment with a whitespace at the beginning

/* This is a comment with a whitespace at the beginning */

/* \nThis is a comment with a whitespace at the beginning */

/*eslint spaced-comment: ["error", "never", { "block": { "balanced": true } }]*/
/*This is a comment with whitespace at the end */

Examples of correct code for this rule with the "never" option:

/*eslint spaced-comment: ["error", "never"]*/

/*This is a comment with no whitespace at the beginning */

/*eslint spaced-comment: ["error", "never"]*/

/**
* I am jsdoc
*/

exceptions

Examples of incorrect code for this rule with the "always" option combined with "exceptions":

/* eslint spaced-comment: ["error", "always", { "block": { "exceptions": ["-"] } }] */

//--------------
// Comment block
//--------------

/* eslint spaced-comment: ["error", "always", { "exceptions": ["-", "+"] }] */

//------++++++++
// Comment block
//------++++++++

/* eslint spaced-comment: ["error", "always", { "exceptions": ["-", "+"] }] */

/*------++++++++*/
/* Comment block */
/*------++++++++*/

/* eslint spaced-comment: ["error", "always", { "line": { "exceptions": ["-+"] } }] */

/*-+-+-+-+-+-+-+*/
// Comment block
/*-+-+-+-+-+-+-+*/

Examples of correct code for this rule with the "always" option combined with "exceptions":

/* eslint spaced-comment: ["error", "always", { "exceptions": ["-"] }] */

//--------------
// Comment block
//--------------

/* eslint spaced-comment: ["error", "always", { "line": { "exceptions": ["-"] } }] */

//--------------
// Comment block
//--------------

/* eslint spaced-comment: ["error", "always", { "exceptions": ["*"] }] */

/****************
 * Comment block
 ****************/

/* eslint spaced-comment: ["error", "always", { "exceptions": ["-+"] }] */

//-+-+-+-+-+-+-+
// Comment block
//-+-+-+-+-+-+-+

/*-+-+-+-+-+-+-+*/
// Comment block
/*-+-+-+-+-+-+-+*/

/* eslint spaced-comment: ["error", "always", { "block": { "exceptions": ["-+"] } }] */

/*-+-+-+-+-+-+-+*/
// Comment block
/*-+-+-+-+-+-+-+*/

markers

Examples of incorrect code for this rule with the "always" option combined with "markers":

/* eslint spaced-comment: ["error", "always", { "markers": ["/"] }] */

///This is a comment with a marker but without whitespace

/*eslint spaced-comment: ["error", "always", { "block": { "markers": ["!"], "balanced": true } }]*/
/*! This is a comment with a marker but without whitespace at the end*/

/*eslint spaced-comment: ["error", "never", { "block": { "markers": ["!"], "balanced": true } }]*/
/*!This is a comment with a marker but with whitespace at the end */

Examples of correct code for this rule with the "always" option combined with "markers":

/* eslint spaced-comment: ["error", "always", { "markers": ["/"] }] */

/// This is a comment with a marker

/*eslint spaced-comment: ["error", "never", { "markers": ["!<"] }]*/

//!<this is a line comment with marker block subsequent lines are ignored></this>

/* eslint spaced-comment: ["error", "always", { "markers": ["global"] }] */

/*global ABC*/

Related Rules

• [spaced-line-comment](spaced-line-comment.md) Source: http://eslint.org/docs/rules/

  Array.prototype.includes = function(searchElement /*, fromIndex*/ ) {

Close

Disallow or enforce spaces inside of parentheses (space-in-parens)

Some style guides require or disallow spaces inside of parentheses:

foo( 'bar' );
var x = ( 1 + 2 ) * 3;

foo('bar');
var x = (1 + 2) * 3;

Rule Details

This rule will enforce consistency of spacing directly inside of parentheses, by disallowing or requiring one or more spaces to the right of ( and to the left of ). In either case, () will still be allowed.

Options

There are two options for this rule:

• "never" (default) enforces zero spaces inside of parentheses
• "always" enforces a space inside of parentheses

Depending on your coding conventions, you can choose either option by specifying it in your configuration:

"space-in-parens": ["error", "always"]

"never"

Examples of incorrect code for this rule with the default "never" option:

/*eslint space-in-parens: ["error", "never"]*/

foo( 'bar');
foo('bar' );
foo( 'bar' );

var foo = ( 1 + 2 ) * 3;
( function () { return 'bar'; }() );

Examples of correct code for this rule with the default "never" option:

/*eslint space-in-parens: ["error", "never"]*/

foo();

foo('bar');

var foo = (1 + 2) * 3;
(function () { return 'bar'; }());

"always"

Examples of incorrect code for this rule with the "always" option:

/*eslint space-in-parens: ["error", "always"]*/

foo( 'bar');
foo('bar' );
foo('bar');

var foo = (1 + 2) * 3;
(function () { return 'bar'; }());

Examples of correct code for this rule with the "always" option:

/*eslint space-in-parens: ["error", "always"]*/

foo();

foo( 'bar' );

var foo = ( 1 + 2 ) * 3;
( function () { return 'bar'; }() );

Exceptions

An object literal may be used as a third array item to specify exceptions, with the key "exceptions" and an array as the value. These exceptions work in the context of the first option. That is, if "always" is set to enforce spacing, then any "exception" will disallow spacing. Conversely, if "never" is set to disallow spacing, then any "exception" will enforce spacing.

The following exceptions are available: ["{}", "[]", "()", "empty"].

Examples of incorrect code for this rule with the "never", { "exceptions": ["{}"] } option:

/*eslint space-in-parens: ["error", "never", { "exceptions": ["{}"] }]*/

foo({bar: 'baz'});
foo(1, {bar: 'baz'});

Examples of correct code for this rule with the "never", { "exceptions": ["{}"] } option:

/*eslint space-in-parens: ["error", "never", { "exceptions": ["{}"] }]*/

foo( {bar: 'baz'} );
foo(1, {bar: 'baz'} );

Examples of incorrect code for this rule with the "always", { "exceptions": ["{}"] } option:

/*eslint space-in-parens: ["error", "always", { "exceptions": ["{}"] }]*/

foo( {bar: 'baz'} );
foo( 1, {bar: 'baz'} );

Examples of correct code for this rule with the "always", { "exceptions": ["{}"] } option:

/*eslint space-in-parens: ["error", "always", { "exceptions": ["{}"] }]*/

foo({bar: 'baz'});
foo( 1, {bar: 'baz'});

Examples of incorrect code for this rule with the "never", { "exceptions": ["[]"] } option:

/*eslint space-in-parens: ["error", "never", { "exceptions": ["[]"] }]*/

foo([bar, baz]);
foo([bar, baz], 1);

Examples of correct code for this rule with the "never", { "exceptions": ["[]"] } option:

/*eslint space-in-parens: ["error", "never", { "exceptions": ["[]"] }]*/

foo( [bar, baz] );
foo( [bar, baz], 1);

Examples of incorrect code for this rule with the "always", { "exceptions": ["[]"] } option:

/*eslint space-in-parens: ["error", "always", { "exceptions": ["[]"] }]*/

foo( [bar, baz] );
foo( [bar, baz], 1 );

Examples of correct code for this rule with the "always", { "exceptions": ["[]"] } option:

/*eslint space-in-parens: ["error", "always", { "exceptions": ["[]"] }]*/

foo([bar, baz]);
foo([bar, baz], 1 );

Examples of incorrect code for this rule with the "never", { "exceptions": ["()"] }] option:

/*eslint space-in-parens: ["error", "never", { "exceptions": ["()"] }]*/

foo((1 + 2));
foo((1 + 2), 1);

Examples of correct code for this rule with the "never", { "exceptions": ["()"] }] option:

/*eslint space-in-parens: ["error", "never", { "exceptions": ["()"] }]*/

foo( (1 + 2) );
foo( (1 + 2), 1);

Examples of incorrect code for this rule with the "always", { "exceptions": ["()"] }] option:

/*eslint space-in-parens: ["error", "always", { "exceptions": ["()"] }]*/

foo( ( 1 + 2 ) );
foo( ( 1 + 2 ), 1 );

Examples of correct code for this rule with the "always", { "exceptions": ["()"] }] option:

/*eslint space-in-parens: ["error", "always", { "exceptions": ["()"] }]*/

foo(( 1 + 2 ));
foo(( 1 + 2 ), 1 );

The "empty" exception concerns empty parentheses, and works the same way as the other exceptions, inverting the first option.

Example of incorrect code for this rule with the "never", { "exceptions": ["empty"] }] option:

/*eslint space-in-parens: ["error", "never", { "exceptions": ["empty"] }]*/

foo();

Example of correct code for this rule with the "never", { "exceptions": ["empty"] }] option:

/*eslint space-in-parens: ["error", "never", { "exceptions": ["empty"] }]*/

foo( );

Example of incorrect code for this rule with the "always", { "exceptions": ["empty"] }] option:

/*eslint space-in-parens: ["error", "always", { "exceptions": ["empty"] }]*/

foo( );

Example of correct code for this rule with the "always", { "exceptions": ["empty"] }] option:

/*eslint space-in-parens: ["error", "always", { "exceptions": ["empty"] }]*/

foo();

You can include multiple entries in the "exceptions" array.

Examples of incorrect code for this rule with the "always", { "exceptions": ["{}", "[]"] }] option:

/*eslint space-in-parens: ["error", "always", { "exceptions": ["{}", "[]"] }]*/

bar( {bar:'baz'} );
baz( 1, [1,2] );
foo( {bar: 'baz'}, [1, 2] );

Examples of correct code for this rule with the "always", { "exceptions": ["{}", "[]"] }] option:

/*eslint space-in-parens: ["error", "always", { "exceptions": ["{}", "[]"] }]*/

bar({bar:'baz'});
baz( 1, [1,2]);
foo({bar: 'baz'}, [1, 2]);

When Not To Use It

You can turn this rule off if you are not concerned with the consistency of spacing between parentheses.

Related Rules

• [space-in-brackets](space-in-brackets.md) (deprecated) Source: http://eslint.org/docs/rules/

Close

disallow multiple empty lines (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.

Rule Details

This rule aims to reduce the scrolling required when reading through your code. It will warn when the maximum amount of empty lines has been exceeded.

Options

This rule has an object option:

• "max" (default: 2) enforces a maximum number of consecutive empty lines.
• "maxEOF" enforces a maximum number of consecutive empty lines at the end of files.
• "maxBOF" enforces a maximum number of consecutive empty lines at the beginning of files.

max

Examples of incorrect code for this rule with the default { "max": 2 } option:

/*eslint no-multiple-empty-lines: "error"*/

var foo = 5;



var bar = 3;

Examples of correct code for this rule with the default { "max": 2 } option:

/*eslint no-multiple-empty-lines: "error"*/

var foo = 5;


var bar = 3;

maxEOF

Examples of incorrect code for this rule with the { max: 2, maxEOF: 1 } options:

/*eslint no-multiple-empty-lines: ["error", { "max": 2, "maxEOF": 1 }]*/

var foo = 5;


var bar = 3;

Examples of correct code for this rule with the { max: 2, maxEOF: 1 } options:

/*eslint no-multiple-empty-lines: ["error", { "max": 2, "maxEOF": 1 }]*/

var foo = 5;


var bar = 3;

maxBOF

Examples of incorrect code for this rule with the { max: 2, maxBOF: 1 } options:

/*eslint no-multiple-empty-lines: ["error", { "max": 2, "maxBOF": 1 }]*/


var foo = 5;


var bar = 3;

Examples of correct code for this rule with the { max: 2, maxBOF: 1 } options:

/*eslint no-multiple-empty-lines: ["error", { "max": 2, "maxBOF": 1}]*/

var foo = 5;


var bar = 3;

When Not To Use It

If you do not care about extra blank lines, turn this off. Source: http://eslint.org/docs/rules/

        (searchElement !== searchElement && currentElement !== currentElement)) { // NaN !== NaN

Close

Disallow Self Compare (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.

Rule Details

This error is raised to highlight a potentially confusing and potentially pointless piece of code. There are almost no situations in which you would need to compare something to itself.

Examples of incorrect code for this rule:

/*eslint no-self-compare: "error"*/

var x = 10;
if (x === x) {
    x = 20;
}

Source: http://eslint.org/docs/rules/

  Array.prototype.includes = function(searchElement /*, fromIndex*/ ) {

Close

Disallow Extending of Native Objects (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.

For example here we are overriding a builtin method that will then affect all Objects, even other builtins.

// seems harmless
Object.prototype.extra = 55;

// loop through some userIds
var users = {
    "123": "Stan",
    "456": "David"
};

// not what you'd expect
for (var id in users) {
    console.log(id); // "123", "456", "extra"
}

A common suggestion to avoid this problem would be to wrap the inside of the for loop with users.hasOwnProperty(id). However, if this rule is strictly enforced throughout your codebase you won't need to take that step.

Rule Details

Disallows directly modifying the prototype of builtin objects.

Examples of incorrect code for this rule:

/*eslint no-extend-native: "error"*/

Object.prototype.a = "a";
Object.defineProperty(Array.prototype, "times", { value: 999 });

Options

This rule accepts an exceptions option, which can be used to specify a list of builtins for which extensions will be allowed.

exceptions

Examples of correct code for the sample { "exceptions": ["Object"] } option:

/*eslint no-extend-native: ["error", { "exceptions": ["Object"] }]*/

Object.prototype.a = "a";

Known Limitations

This rule does not report any of the following less obvious approaches to modify the prototype of builtin objects:

var x = Object;
x.prototype.thing = a;

eval("Array.prototype.forEach = 'muhahaha'");

with(Array) {
    prototype.thing = 'thing';
};

window.Function.prototype.bind = 'tight';

When Not To Use It

You may want to disable this rule when working with polyfills that try to patch older versions of JavaScript with the latest spec, such as those that might Function.prototype.bind or Array.prototype.forEach in a future-friendly way.

Related Rules

• [no-global-assign](no-global-assign.md) Source: http://eslint.org/docs/rules/

        (searchElement !== searchElement && currentElement !== currentElement)) { // NaN !== NaN

Close

Disallow Self Compare (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.

Rule Details

This error is raised to highlight a potentially confusing and potentially pointless piece of code. There are almost no situations in which you would need to compare something to itself.

Examples of incorrect code for this rule:

/*eslint no-self-compare: "error"*/

var x = 10;
if (x === x) {
    x = 20;
}

Source: http://eslint.org/docs/rules/