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

Require parens in arrow function arguments (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.

Rule Details

This rule enforces parentheses around arrow function parameters regardless of arity. For example:

/*eslint-env es6*/

// Bad
a => {}

// Good
(a) => {}

Following this style will help you find arrow functions (=>) which may be mistakenly included in a condition when a comparison such as >= was the intent.

/*eslint-env es6*/

// Bad
if (a => 2) {
}

// Good
if (a >= 2) {
}

The rule can also be configured to discourage the use of parens when they are not required:

/*eslint-env es6*/

// Bad
(a) => {}

// Good
a => {}

Options

This rule has a string option and an object one.

String options are:

• "always" (default) requires parens around arguments in all cases.
• "as-needed" allows omitting parens when there is only one argument.

Object properties for variants of the "as-needed" option:

• "requireForBlockBody": true modifies the as-needed rule in order to require parens if the function body is in an instructions block (surrounded by braces).

always

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

/*eslint arrow-parens: ["error", "always"]*/
/*eslint-env es6*/

a => {};
a => a;
a => {'\n'};
a.then(foo => {});
a.then(foo => a);
a(foo => { if (true) {} });

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

/*eslint arrow-parens: ["error", "always"]*/
/*eslint-env es6*/

() => {};
(a) => {};
(a) => a;
(a) => {'\n'}
a.then((foo) => {});
a.then((foo) => { if (true) {} });

If Statements

One of benefits of this option is that it prevents the incorrect use of arrow functions in conditionals:

/*eslint-env es6*/

var a = 1;
var b = 2;
// ...
if (a => b) {
 console.log('bigger');
} else {
 console.log('smaller');
}
// outputs 'bigger', not smaller as expected

The contents of the if statement is an arrow function, not a comparison.

If the arrow function is intentional, it should be wrapped in parens to remove ambiguity.

/*eslint-env es6*/

var a = 1;
var b = 0;
// ...
if ((a) => b) {
 console.log('truthy value returned');
} else {
 console.log('falsey value returned');
}
// outputs 'truthy value returned'

The following is another example of this behavior:

/*eslint-env es6*/

var a = 1, b = 2, c = 3, d = 4;
var f = a => b ? c: d;
// f = ?

f is an arrow function which takes a as an argument and returns the result of b ? c: d.

This should be rewritten like so:

/*eslint-env es6*/

var a = 1, b = 2, c = 3, d = 4;
var f = (a) => b ? c: d;

as-needed

Examples of incorrect code for this rule with the "as-needed" option:

/*eslint arrow-parens: ["error", "as-needed"]*/
/*eslint-env es6*/

(a) => {};
(a) => a;
(a) => {'\n'};
a.then((foo) => {});
a.then((foo) => a);
a((foo) => { if (true) {} });

Examples of correct code for this rule with the "as-needed" option:

/*eslint arrow-parens: ["error", "as-needed"]*/
/*eslint-env es6*/

() => {};
a => {};
a => a;
a => {'\n'};
a.then(foo => {});
a.then(foo => { if (true) {} });
(a, b, c) => a;
(a = 10) => a;
([a, b]) => a;
({a, b}) => a;

requireForBlockBody

Examples of incorrect code for the { "requireForBlockBody": true } option:

/*eslint arrow-parens: [2, "as-needed", { "requireForBlockBody": true }]*/
/*eslint-env es6*/

(a) => a;
a => {};
a => {'\n'};
a.map((x) => x * x);
a.map(x => {
  return x * x;
});
a.then(foo => {});

Examples of correct code for the { "requireForBlockBody": true } option:

/*eslint arrow-parens: [2, "as-needed", { "requireForBlockBody": true }]*/
/*eslint-env es6*/

(a) => {};
(a) => {'\n'};
a => ({});
() => {};
a => a;
a.then((foo) => {});
a.then((foo) => { if (true) {} });
a((foo) => { if (true) {} });
(a, b, c) => a;
(a = 10) => a;
([a, b]) => a;
({a, b}) => a;

Further Reading

• The "as-needed", { "requireForBlockBody": true } rule is directly inspired by the Airbnb JS Style Guide. Source: http://eslint.org/docs/rules/

enforce consistent line breaks inside braces (object-curly-newline)

A number of style guides require or disallow line breaks inside of object braces and other tokens.

Rule Details

This rule enforces consistent line breaks inside braces of object literals or destructuring assignments.

Options

This rule has either a string option:

• "always" requires line breaks inside braces
• "never" disallows line breaks inside braces

Or an object option:

• "multiline": true requires line breaks if there are line breaks inside properties or between properties
• "minProperties" requires line breaks if the number of properties is at least the given integer. By default, an error will also be reported if an object contains linebreaks and has fewer properties than the given integer. However, the second behavior is disabled if the consistent option is set to true
• "consistent": true (default) requires that either both curly braces, or neither, directly enclose newlines. Note that enabling this option will also change the behavior of the minProperties option. (See minProperties above for more information)

You can specify different options for object literals, destructuring assignments, and named imports and exports:

{
    "object-curly-newline": ["error", {
        "ObjectExpression": "always",
        "ObjectPattern": { "multiline": true },
        "ImportDeclaration": "never",
        "ExportDeclaration": { "multiline": true, "minProperties": 3 }
    }]
}

• "ObjectExpression" configuration for object literals
• "ObjectPattern" configuration for object patterns of destructuring assignments
• "ImportDeclaration" configuration for named imports
• "ExportDeclaration" configuration for named exports

always

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

/*eslint object-curly-newline: ["error", "always"]*/
/*eslint-env es6*/

let a = {};
let b = {foo: 1};
let c = {foo: 1, bar: 2};
let d = {foo: 1,
    bar: 2};
let e = {foo() {
    dosomething();
}};

let {} = obj;
let {f} = obj;
let {g, h} = obj;
let {i,
    j} = obj;
let {k = function() {
    dosomething();
}} = obj;

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

/*eslint object-curly-newline: ["error", "always"]*/
/*eslint-env es6*/

let a = {
};
let b = {
    foo: 1
};
let c = {
    foo: 1, bar: 2
};
let d = {
    foo: 1,
    bar: 2
};
let e = {
    foo: function() {
        dosomething();
    }
};

let {
} = obj;
let {
    f
} = obj;
let {
    g, h
} = obj;
let {
    i,
    j
} = obj;
let {
    k = function() {
        dosomething();
    }
} = obj;

never

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

/*eslint object-curly-newline: ["error", "never"]*/
/*eslint-env es6*/

let a = {
};
let b = {
    foo: 1
};
let c = {
    foo: 1, bar: 2
};
let d = {
    foo: 1,
    bar: 2
};
let e = {
    foo: function() {
        dosomething();
    }
};

let {
} = obj;
let {
    f
} = obj;
let {
    g, h
} = obj;
let {
    i,
    j
} = obj;
let {
    k = function() {
        dosomething();
    }
} = obj;

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

/*eslint object-curly-newline: ["error", "never"]*/
/*eslint-env es6*/

let a = {};
let b = {foo: 1};
let c = {foo: 1, bar: 2};
let d = {foo: 1,
    bar: 2};
let e = {foo: function() {
    dosomething();
}};

let {} = obj;
let {f} = obj;
let {g, h} = obj;
let {i,
    j} = obj;
let {k = function() {
    dosomething();
}} = obj;

multiline

Examples of incorrect code for this rule with the { "multiline": true } option:

/*eslint object-curly-newline: ["error", { "multiline": true }]*/
/*eslint-env es6*/

let a = {
};
let b = {
    foo: 1
};
let c = {
    foo: 1, bar: 2
};
let d = {foo: 1,
    bar: 2};
let e = {foo: function() {
    dosomething();
}};

let {
} = obj;
let {
    f
} = obj;
let {
    g, h
} = obj;
let {i,
    j} = obj;
let {k = function() {
    dosomething();
}} = obj;

Examples of correct code for this rule with the { "multiline": true } option:

/*eslint object-curly-newline: ["error", { "multiline": true }]*/
/*eslint-env es6*/

let a = {};
let b = {foo: 1};
let c = {foo: 1, bar: 2};
let d = {
    foo: 1,
    bar: 2
};
let e = {
    foo: function() {
        dosomething();
    }
};

let {} = obj;
let {f} = obj;
let {g, h} = obj;
let {
    i,
    j
} = obj;
let {
    k = function() {
        dosomething();
    }
} = obj;

minProperties

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

/*eslint object-curly-newline: ["error", { "minProperties": 2 }]*/
/*eslint-env es6*/

let a = {
};
let b = {
    foo: 1
};
let c = {foo: 1, bar: 2};
let d = {foo: 1,
    bar: 2};
let e = {
    foo: function() {
        dosomething();
    }
};

let {
} = obj;
let {
    f
} = obj;
let {g, h} = obj;
let {i,
    j} = obj;
let {
    k = function() {
        dosomething();
    }
} = obj;

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

/*eslint object-curly-newline: ["error", { "minProperties": 2 }]*/
/*eslint-env es6*/

let a = {};
let b = {foo: 1};
let c = {
    foo: 1, bar: 2
};
let d = {
    foo: 1,
    bar: 2
};
let e = {foo: function() {
    dosomething();
}};

let {} = obj;
let {f} = obj;
let {
    g, h
} = obj;
let {
    i,
    j
} = obj;
let {k = function() {
    dosomething();
}} = obj;

consistent

Examples of incorrect code for this rule with the default { "consistent": true } option:

/*eslint object-curly-newline: ["error", { "consistent": true }]*/
/*eslint-env es6*/

let a = {foo: 1
};
let b = {
    foo: 1};
let c = {foo: 1, bar: 2
};
let d = {
    foo: 1, bar: 2};
let e = {foo: 1,
    bar: 2};
let f = {foo: function() {
    dosomething();
}};

let {g
} = obj;
let {
    h} = obj;
let {i, j
} = obj;
let {
    k, l} = obj;
let {m,
    n} = obj;
let {o = function() {
    dosomething();
}} = obj;

Examples of correct code for this rule with the default { "consistent": true } option:

/*eslint object-curly-newline: ["error", { "consistent": true }]*/
/*eslint-env es6*/

let a = {};
let b = {foo: 1};
let c = {
    foo: 1
};
let d = {
    foo: 1, bar: 2
};
let e = {
    foo: 1,
    bar: 2
};
let f = {foo: function() {dosomething();}};
let g = {
    foo: function() {
        dosomething();
    }
};

let {} = obj;
let {h} = obj;
let {i, j} = obj;
let {
    k, l
} = obj;
let {
    m,
    n
} = obj;
let {o = function() {dosomething();}} = obj;
let {
    p = function() {
        dosomething();
    }
} = obj;

ObjectExpression and ObjectPattern

Examples of incorrect code for this rule with the { "ObjectExpression": "always", "ObjectPattern": "never" } options:

/*eslint object-curly-newline: ["error", { "ObjectExpression": "always", "ObjectPattern": "never" }]*/
/*eslint-env es6*/

let a = {};
let b = {foo: 1};
let c = {foo: 1, bar: 2};
let d = {foo: 1,
    bar: 2};
let e = {foo: function() {
    dosomething();
}};

let {
} = obj;
let {
    f
} = obj;
let {
    g, h
} = obj;
let {
    i,
    j
} = obj;
let {
    k = function() {
        dosomething();
    }
} = obj;

Examples of correct code for this rule with the { "ObjectExpression": "always", "ObjectPattern": "never" } options:

/*eslint object-curly-newline: ["error", { "ObjectExpression": "always", "ObjectPattern": "never" }]*/
/*eslint-env es6*/

let a = {
};
let b = {
    foo: 1
};
let c = {
    foo: 1, bar: 2
};
let d = {
    foo: 1,
    bar: 2
};
let e = {
    foo: function() {
        dosomething();
    }
};

let {} = obj;
let {f} = obj;
let {g, h} = obj;
let {i,
    j} = obj;
let {k = function() {
    dosomething();
}} = obj;

ImportDeclaration and ExportDeclaration

Examples of incorrect code for this rule with the { "ImportDeclaration": "always", "ExportDeclaration": "never" } options:

/*eslint object-curly-newline: ["error", { "ImportDeclaration": "always", "ExportDeclaration": "never" }]*/
/*eslint-env es6*/

import {foo, bar} from 'foo-bar';
import {foo as f, bar} from 'foo-bar';
import {foo,
    bar} from 'foo-bar';

export {
   foo,
   bar
};
export {
   foo as f,
   bar
} from 'foo-bar';

Examples of correct code for this rule with the { "ImportDeclaration": "always", "ExportDeclaration": "never" } options:

/*eslint object-curly-newline: ["error", { "ImportDeclaration": "always", "ExportDeclaration": "never" }]*/
/*eslint-env es6*/

import {
    foo,
    bar
} from 'foo-bar';
import {
    foo as f,
    bar
} from 'foo-bar';

export { foo, bar } from 'foo-bar';
export { foo as f, bar } from 'foo-bar';

Compatibility

• JSCS: requirePaddingNewLinesInObjects
• JSCS: disallowPaddingNewLinesInObjects

When Not To Use It

If you don't want to enforce consistent line breaks inside braces, then it's safe to disable this rule.

Related Rules

• [comma-spacing](comma-spacing.md)
• [key-spacing](key-spacing.md)
• [object-curly-spacing](object-curly-spacing.md)
• [object-property-newline](object-property-newline.md) Source: http://eslint.org/docs/rules/

Require Dot Notation (dot-notation)

In JavaScript, one can access properties using the dot notation (foo.bar) 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.

foo["bar"];

Rule Details

This rule is aimed at maintaining code consistency and improving code readability by encouraging use of the dot notation style whenever possible. As such, it will warn when it encounters an unnecessary use of square-bracket notation.

Examples of incorrect code for this rule:

/*eslint dot-notation: "error"*/

var x = foo["bar"];

Examples of correct code for this rule:

/*eslint dot-notation: "error"*/

var x = foo.bar;

var x = foo[bar];    // Property name is a variable, square-bracket notation required

Options

This rule accepts a single options argument:

• Set the allowKeywords option to false (default is true) to follow ECMAScript version 3 compatible style, avoiding dot notation for reserved word properties.
• Set the allowPattern option to a regular expression string to allow bracket notation for property names that match a pattern (by default, no pattern is tested).

allowKeywords

Examples of correct code for the { "allowKeywords": false } option:

/*eslint dot-notation: ["error", { "allowKeywords": false }]*/

var foo = { "class": "CS 101" }
var x = foo["class"]; // Property name is a reserved word, square-bracket notation required

allowPattern

For example, when preparing data to be sent to an external API, it is often required to use property names that include underscores. If the camelcase rule is in effect, these snake case properties would not be allowed. By providing an allowPattern to the dot-notation rule, these snake case properties can be accessed with bracket notation.

Examples of correct code for the sample { "allowPattern": "^[a-z]+(_[a-z]+)+$" } option:

/*eslint camelcase: "error"*/
/*eslint dot-notation: ["error", { "allowPattern": "^[a-z]+(_[a-z]+)+$" }]*/

var data = {};
data.foo_bar = 42;

var data = {};
data["fooBar"] = 42;

var data = {};
data["foo_bar"] = 42; // no warning

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

enforce variables to be declared either together or separately in functions (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.

For instance:

// one variable declaration per function
function foo() {
    var bar, baz;
}

// multiple variable declarations per function
function foo() {
    var bar;
    var baz;
}

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.

Rule Details

This rule enforces variables to be declared either together or separately per function ( for var) or block (for let and const) scope.

Options

This rule has one option, which can be a string option or an object option.

String option:

• "always" (default) requires one variable declaration per scope
• "never" requires multiple variable declarations per scope
• "consecutive" allows multiple variable declarations per scope but requires consecutive variable declarations to be combined into a single declaration

Object option:

• "var": "always" requires one var declaration per function
• "var": "never" requires multiple var declarations per function
• "var": "consecutive" requires consecutive var declarations to be a single declaration
• "let": "always" requires one let declaration per block
• "let": "never" requires multiple let declarations per block
• "let": "consecutive" requires consecutive let declarations to be a single declaration
• "const": "always" requires one const declaration per block
• "const": "never" requires multiple const declarations per block
• "const": "consecutive" requires consecutive const declarations to be a single declaration
• "separateRequires": true enforces requires to be separate from declarations

Alternate object option:

• "initialized": "always" requires one variable declaration for initialized variables per scope
• "initialized": "never" requires multiple variable declarations for initialized variables per scope
• "initialized": "consecutive" requires consecutive variable declarations for initialized variables to be a single declaration
• "uninitialized": "always" requires one variable declaration for uninitialized variables per scope
• "uninitialized": "never" requires multiple variable declarations for uninitialized variables per scope
• "uninitialized": "consecutive" requires consecutive variable declarations for uninitialized variables to be a single declaration

always

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

/*eslint one-var: ["error", "always"]*/
/*eslint-env es6*/

function foo() {
    var bar;
    var baz;
    let qux;
    let norf;
}

function foo(){
    const bar = false;
    const baz = true;
    let qux;
    let norf;
}

function foo() {
    var bar;

    if (baz) {
        var qux = true;
    }
}

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

/*eslint one-var: ["error", "always"]*/
/*eslint-env es6*/

function foo() {
    var bar,
        baz;
    let qux,
        norf;
}

function foo(){
    const bar = true,
        baz = false;
    let qux,
        norf;
}

function foo() {
    var bar,
        qux;

    if (baz) {
        qux = true;
    }
}

function foo(){
    let bar;

    if (baz) {
        let qux;
    }
}

never

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

/*eslint one-var: ["error", "never"]*/
/*eslint-env es6*/

function foo() {
    var bar,
        baz;
    const bar = true,
        baz = false;
}

function foo() {
    var bar,
        qux;

    if (baz) {
        qux = true;
    }
}

function foo(){
    let bar = true,
        baz = false;
}

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

/*eslint one-var: ["error", "never"]*/
/*eslint-env es6*/

function foo() {
    var bar;
    var baz;
}

function foo() {
    var bar;

    if (baz) {
        var qux = true;
    }
}

function foo() {
    let bar;

    if (baz) {
        let qux = true;
    }
}

consecutive

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

/*eslint one-var: ["error", "consecutive"]*/
/*eslint-env es6*/

function foo() {
    var bar;
    var baz;
}

function foo(){
    var bar = 1;
    var baz = 2;

    qux();

    var qux = 3;
    var quux;
}

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

/*eslint one-var: ["error", "consecutive"]*/
/*eslint-env es6*/


function foo() {
    var bar,
        baz;
}

function foo(){
    var bar = 1,
        baz = 2;

    qux();

    var qux = 3,
        quux;
}

var, let, and const

Examples of incorrect code for this rule with the { var: "always", let: "never", const: "never" } option:

/*eslint one-var: ["error", { var: "always", let: "never", const: "never" }]*/
/*eslint-env es6*/

function foo() {
    var bar;
    var baz;
    let qux,
        norf;
}

function foo() {
    const bar = 1,
          baz = 2;
    let qux,
        norf;
}

Examples of correct code for this rule with the { var: "always", let: "never", const: "never" } option:

/*eslint one-var: ["error", { var: "always", let: "never", const: "never" }]*/
/*eslint-env es6*/

function foo() {
    var bar,
        baz;
    let qux;
    let norf;
}

function foo() {
    const bar = 1;
    const baz = 2;
    let qux;
    let norf;
}

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

/*eslint one-var: ["error", { var: "never" }]*/
/*eslint-env es6*/

function foo() {
    var bar,
        baz;
}

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

/*eslint one-var: ["error", { var: "never" }]*/
/*eslint-env es6*/

function foo() {
    var bar,
        baz;
    const bar = 1; // `const` and `let` declarations are ignored if they are not specified
    const baz = 2;
    let qux;
    let norf;
}

Examples of incorrect code for this rule with the { separateRequires: true } option:

/*eslint one-var: ["error", { separateRequires: true, var: "always" }]*/
/*eslint-env node*/

var foo = require("foo"),
    bar = "bar";

Examples of correct code for this rule with the { separateRequires: true } option:

/*eslint one-var: ["error", { separateRequires: true, var: "always" }]*/
/*eslint-env node*/

var foo = require("foo");
var bar = "bar";

var foo = require("foo"),
    bar = require("bar");

Examples of incorrect code for this rule with the { var: "never", let: "consecutive", const: "consecutive" } option:

/*eslint one-var: ["error", { var: "never", let: "consecutive", const: "consecutive" }]*/
/*eslint-env es6*/

function foo() {
    let a,
        b;
    let c;

    var d,
        e;
}

function foo() {
    const a = 1,
        b = 2;
    const c = 3;

    var d,
        e;
}

Examples of correct code for this rule with the { var: "never", let: "consecutive", const: "consecutive" } option:

/*eslint one-var: ["error", { var: "never", let: "consecutive", const: "consecutive" }]*/
/*eslint-env es6*/

function foo() {
    let a,
        b;

    var d;
    var e;

    let f;
}

function foo() {
    const a = 1,
          b = 2;

    var c;
    var d;

    const e = 3;
}

Examples of incorrect code for this rule with the { var: "consecutive" } option:

/*eslint one-var: ["error", { var: "consecutive" }]*/
/*eslint-env es6*/

function foo() {
    var a;
    var b;
}

Examples of correct code for this rule with the { var: "consecutive" } option:

/*eslint one-var: ["error", { var: "consecutive" }]*/
/*eslint-env es6*/

function foo() {
    var a,
        b;
    const c = 1; // `const` and `let` declarations are ignored if they are not specified
    const d = 2;
    let e;
    let f;
}

initialized and uninitialized

Examples of incorrect code for this rule with the { "initialized": "always", "uninitialized": "never" } option:

/*eslint one-var: ["error", { "initialized": "always", "uninitialized": "never" }]*/
/*eslint-env es6*/

function foo() {
    var a, b, c;
    var foo = true;
    var bar = false;
}

Examples of correct code for this rule with the { "initialized": "always", "uninitialized": "never" } option:

/*eslint one-var: ["error", { "initialized": "always", "uninitialized": "never" }]*/

function foo() {
    var a;
    var b;
    var c;
    var foo = true,
        bar = false;
}

for (let z of foo) {
    doSomething(z);
}

let z;
for (z of foo) {
    doSomething(z);
}

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

/*eslint one-var: ["error", { "initialized": "never" }]*/
/*eslint-env es6*/

function foo() {
    var foo = true,
        bar = false;
}

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

/*eslint one-var: ["error", { "initialized": "never" }]*/

function foo() {
    var foo = true;
    var bar = false;
    var a, b, c; // Uninitialized variables are ignored
}

Examples of incorrect code for this rule with the { "initialized": "consecutive", "uninitialized": "never" } option:

/*eslint one-var: ["error", { "initialized": "consecutive", "uninitialized": "never" }]*/

function foo() {
    var a = 1;
    var b = 2;
    var c,
        d;
    var e = 3;
    var f = 4;
}

Examples of correct code for this rule with the { "initialized": "consecutive", "uninitialized": "never" } option:

/*eslint one-var: ["error", { "initialized": "consecutive", "uninitialized": "never" }]*/

function foo() {
    var a = 1,
        b = 2;
    var c;
    var d;
    var e = 3,
        f = 4;
}

Examples of incorrect code for this rule with the { "initialized": "consecutive" } option:

/*eslint one-var: ["error", { "initialized": "consecutive" }]*/

function foo() {
    var a = 1;
    var b = 2;

    foo();

    var c = 3;
    var d = 4;
}

Examples of correct code for this rule with the { "initialized": "consecutive" } option:

/*eslint one-var: ["error", { "initialized": "consecutive" }]*/

function foo() {
    var a = 1,
        b = 2;

    foo();

    var c = 3,
        d = 4;
}

Compatibility

• JSHint: This rule maps to the onevar JSHint rule, but allows let and const to be configured separately.
• JSCS: This rule roughly maps to disallowMultipleVarDecl.
• JSCS: This rule option separateRequires roughly maps to requireMultipleVarDecl. Source: http://eslint.org/docs/rules/

Require Variable Declarations to be at the top of their scope (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.

Rule Details

This rule aims to keep all variable declarations in the leading series of statements. Allowing multiple declarations helps promote maintainability and is thus allowed.

Examples of incorrect code for this rule:

/*eslint vars-on-top: "error"*/

// Variable declarations in a block:
function doSomething() {
    var first;
    if (true) {
        first = true;
    }
    var second;
}

// Variable declaration in for initializer:
function doSomething() {
    for (var i=0; i<10; i++) {}
}

/*eslint vars-on-top: "error"*/

// Variables after other statements:
f();
var a;

Examples of correct code for this rule:

/*eslint vars-on-top: "error"*/

function doSomething() {
    var first;
    var second; //multiple declarations are allowed at the top
    if (true) {
        first = true;
    }
}

function doSomething() {
    var i;
    for (i=0; i<10; i++) {}
}

/*eslint vars-on-top: "error"*/

var a;
f();

/*eslint vars-on-top: "error"*/

// Directives may precede variable declarations.
"use strict";
var a;
f();

// Comments can describe variables.
function doSomething() {
    // this is the first var.
    var first;
    // this is the second var.
    var second
}

Further Reading

• JavaScript Scoping and Hoisting
• var Hoisting
• A criticism of the Single Var Pattern in JavaScript, and a simple alternative
• Multiple var statements in JavaScript, not superfluous Source: http://eslint.org/docs/rules/

enforce consistent line breaks inside braces (object-curly-newline)

A number of style guides require or disallow line breaks inside of object braces and other tokens.

Rule Details

This rule enforces consistent line breaks inside braces of object literals or destructuring assignments.

Options

This rule has either a string option:

• "always" requires line breaks inside braces
• "never" disallows line breaks inside braces

Or an object option:

• "multiline": true requires line breaks if there are line breaks inside properties or between properties
• "minProperties" requires line breaks if the number of properties is at least the given integer. By default, an error will also be reported if an object contains linebreaks and has fewer properties than the given integer. However, the second behavior is disabled if the consistent option is set to true
• "consistent": true (default) requires that either both curly braces, or neither, directly enclose newlines. Note that enabling this option will also change the behavior of the minProperties option. (See minProperties above for more information)

You can specify different options for object literals, destructuring assignments, and named imports and exports:

{
    "object-curly-newline": ["error", {
        "ObjectExpression": "always",
        "ObjectPattern": { "multiline": true },
        "ImportDeclaration": "never",
        "ExportDeclaration": { "multiline": true, "minProperties": 3 }
    }]
}

• "ObjectExpression" configuration for object literals
• "ObjectPattern" configuration for object patterns of destructuring assignments
• "ImportDeclaration" configuration for named imports
• "ExportDeclaration" configuration for named exports

always

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

/*eslint object-curly-newline: ["error", "always"]*/
/*eslint-env es6*/

let a = {};
let b = {foo: 1};
let c = {foo: 1, bar: 2};
let d = {foo: 1,
    bar: 2};
let e = {foo() {
    dosomething();
}};

let {} = obj;
let {f} = obj;
let {g, h} = obj;
let {i,
    j} = obj;
let {k = function() {
    dosomething();
}} = obj;

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

/*eslint object-curly-newline: ["error", "always"]*/
/*eslint-env es6*/

let a = {
};
let b = {
    foo: 1
};
let c = {
    foo: 1, bar: 2
};
let d = {
    foo: 1,
    bar: 2
};
let e = {
    foo: function() {
        dosomething();
    }
};

let {
} = obj;
let {
    f
} = obj;
let {
    g, h
} = obj;
let {
    i,
    j
} = obj;
let {
    k = function() {
        dosomething();
    }
} = obj;

never

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

/*eslint object-curly-newline: ["error", "never"]*/
/*eslint-env es6*/

let a = {
};
let b = {
    foo: 1
};
let c = {
    foo: 1, bar: 2
};
let d = {
    foo: 1,
    bar: 2
};
let e = {
    foo: function() {
        dosomething();
    }
};

let {
} = obj;
let {
    f
} = obj;
let {
    g, h
} = obj;
let {
    i,
    j
} = obj;
let {
    k = function() {
        dosomething();
    }
} = obj;

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

/*eslint object-curly-newline: ["error", "never"]*/
/*eslint-env es6*/

let a = {};
let b = {foo: 1};
let c = {foo: 1, bar: 2};
let d = {foo: 1,
    bar: 2};
let e = {foo: function() {
    dosomething();
}};

let {} = obj;
let {f} = obj;
let {g, h} = obj;
let {i,
    j} = obj;
let {k = function() {
    dosomething();
}} = obj;

multiline

Examples of incorrect code for this rule with the { "multiline": true } option:

/*eslint object-curly-newline: ["error", { "multiline": true }]*/
/*eslint-env es6*/

let a = {
};
let b = {
    foo: 1
};
let c = {
    foo: 1, bar: 2
};
let d = {foo: 1,
    bar: 2};
let e = {foo: function() {
    dosomething();
}};

let {
} = obj;
let {
    f
} = obj;
let {
    g, h
} = obj;
let {i,
    j} = obj;
let {k = function() {
    dosomething();
}} = obj;

Examples of correct code for this rule with the { "multiline": true } option:

/*eslint object-curly-newline: ["error", { "multiline": true }]*/
/*eslint-env es6*/

let a = {};
let b = {foo: 1};
let c = {foo: 1, bar: 2};
let d = {
    foo: 1,
    bar: 2
};
let e = {
    foo: function() {
        dosomething();
    }
};

let {} = obj;
let {f} = obj;
let {g, h} = obj;
let {
    i,
    j
} = obj;
let {
    k = function() {
        dosomething();
    }
} = obj;

minProperties

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

/*eslint object-curly-newline: ["error", { "minProperties": 2 }]*/
/*eslint-env es6*/

let a = {
};
let b = {
    foo: 1
};
let c = {foo: 1, bar: 2};
let d = {foo: 1,
    bar: 2};
let e = {
    foo: function() {
        dosomething();
    }
};

let {
} = obj;
let {
    f
} = obj;
let {g, h} = obj;
let {i,
    j} = obj;
let {
    k = function() {
        dosomething();
    }
} = obj;

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

/*eslint object-curly-newline: ["error", { "minProperties": 2 }]*/
/*eslint-env es6*/

let a = {};
let b = {foo: 1};
let c = {
    foo: 1, bar: 2
};
let d = {
    foo: 1,
    bar: 2
};
let e = {foo: function() {
    dosomething();
}};

let {} = obj;
let {f} = obj;
let {
    g, h
} = obj;
let {
    i,
    j
} = obj;
let {k = function() {
    dosomething();
}} = obj;

consistent

Examples of incorrect code for this rule with the default { "consistent": true } option:

/*eslint object-curly-newline: ["error", { "consistent": true }]*/
/*eslint-env es6*/

let a = {foo: 1
};
let b = {
    foo: 1};
let c = {foo: 1, bar: 2
};
let d = {
    foo: 1, bar: 2};
let e = {foo: 1,
    bar: 2};
let f = {foo: function() {
    dosomething();
}};

let {g
} = obj;
let {
    h} = obj;
let {i, j
} = obj;
let {
    k, l} = obj;
let {m,
    n} = obj;
let {o = function() {
    dosomething();
}} = obj;

Examples of correct code for this rule with the default { "consistent": true } option:

/*eslint object-curly-newline: ["error", { "consistent": true }]*/
/*eslint-env es6*/

let a = {};
let b = {foo: 1};
let c = {
    foo: 1
};
let d = {
    foo: 1, bar: 2
};
let e = {
    foo: 1,
    bar: 2
};
let f = {foo: function() {dosomething();}};
let g = {
    foo: function() {
        dosomething();
    }
};

let {} = obj;
let {h} = obj;
let {i, j} = obj;
let {
    k, l
} = obj;
let {
    m,
    n
} = obj;
let {o = function() {dosomething();}} = obj;
let {
    p = function() {
        dosomething();
    }
} = obj;

ObjectExpression and ObjectPattern

Examples of incorrect code for this rule with the { "ObjectExpression": "always", "ObjectPattern": "never" } options:

/*eslint object-curly-newline: ["error", { "ObjectExpression": "always", "ObjectPattern": "never" }]*/
/*eslint-env es6*/

let a = {};
let b = {foo: 1};
let c = {foo: 1, bar: 2};
let d = {foo: 1,
    bar: 2};
let e = {foo: function() {
    dosomething();
}};

let {
} = obj;
let {
    f
} = obj;
let {
    g, h
} = obj;
let {
    i,
    j
} = obj;
let {
    k = function() {
        dosomething();
    }
} = obj;

Examples of correct code for this rule with the { "ObjectExpression": "always", "ObjectPattern": "never" } options:

/*eslint object-curly-newline: ["error", { "ObjectExpression": "always", "ObjectPattern": "never" }]*/
/*eslint-env es6*/

let a = {
};
let b = {
    foo: 1
};
let c = {
    foo: 1, bar: 2
};
let d = {
    foo: 1,
    bar: 2
};
let e = {
    foo: function() {
        dosomething();
    }
};

let {} = obj;
let {f} = obj;
let {g, h} = obj;
let {i,
    j} = obj;
let {k = function() {
    dosomething();
}} = obj;

ImportDeclaration and ExportDeclaration

Examples of incorrect code for this rule with the { "ImportDeclaration": "always", "ExportDeclaration": "never" } options:

/*eslint object-curly-newline: ["error", { "ImportDeclaration": "always", "ExportDeclaration": "never" }]*/
/*eslint-env es6*/

import {foo, bar} from 'foo-bar';
import {foo as f, bar} from 'foo-bar';
import {foo,
    bar} from 'foo-bar';

export {
   foo,
   bar
};
export {
   foo as f,
   bar
} from 'foo-bar';

Examples of correct code for this rule with the { "ImportDeclaration": "always", "ExportDeclaration": "never" } options:

/*eslint object-curly-newline: ["error", { "ImportDeclaration": "always", "ExportDeclaration": "never" }]*/
/*eslint-env es6*/

import {
    foo,
    bar
} from 'foo-bar';
import {
    foo as f,
    bar
} from 'foo-bar';

export { foo, bar } from 'foo-bar';
export { foo as f, bar } from 'foo-bar';

Compatibility

• JSCS: requirePaddingNewLinesInObjects
• JSCS: disallowPaddingNewLinesInObjects

When Not To Use It

If you don't want to enforce consistent line breaks inside braces, then it's safe to disable this rule.

Related Rules

• [comma-spacing](comma-spacing.md)
• [key-spacing](key-spacing.md)
• [object-curly-spacing](object-curly-spacing.md)
• [object-property-newline](object-property-newline.md) Source: http://eslint.org/docs/rules/

Require parens in arrow function arguments (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.

Rule Details

This rule enforces parentheses around arrow function parameters regardless of arity. For example:

/*eslint-env es6*/

// Bad
a => {}

// Good
(a) => {}

Following this style will help you find arrow functions (=>) which may be mistakenly included in a condition when a comparison such as >= was the intent.

/*eslint-env es6*/

// Bad
if (a => 2) {
}

// Good
if (a >= 2) {
}

The rule can also be configured to discourage the use of parens when they are not required:

/*eslint-env es6*/

// Bad
(a) => {}

// Good
a => {}

Options

This rule has a string option and an object one.

String options are:

• "always" (default) requires parens around arguments in all cases.
• "as-needed" allows omitting parens when there is only one argument.

Object properties for variants of the "as-needed" option:

• "requireForBlockBody": true modifies the as-needed rule in order to require parens if the function body is in an instructions block (surrounded by braces).

always

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

/*eslint arrow-parens: ["error", "always"]*/
/*eslint-env es6*/

a => {};
a => a;
a => {'\n'};
a.then(foo => {});
a.then(foo => a);
a(foo => { if (true) {} });

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

/*eslint arrow-parens: ["error", "always"]*/
/*eslint-env es6*/

() => {};
(a) => {};
(a) => a;
(a) => {'\n'}
a.then((foo) => {});
a.then((foo) => { if (true) {} });

If Statements

One of benefits of this option is that it prevents the incorrect use of arrow functions in conditionals:

/*eslint-env es6*/

var a = 1;
var b = 2;
// ...
if (a => b) {
 console.log('bigger');
} else {
 console.log('smaller');
}
// outputs 'bigger', not smaller as expected

The contents of the if statement is an arrow function, not a comparison.

If the arrow function is intentional, it should be wrapped in parens to remove ambiguity.

/*eslint-env es6*/

var a = 1;
var b = 0;
// ...
if ((a) => b) {
 console.log('truthy value returned');
} else {
 console.log('falsey value returned');
}
// outputs 'truthy value returned'

The following is another example of this behavior:

/*eslint-env es6*/

var a = 1, b = 2, c = 3, d = 4;
var f = a => b ? c: d;
// f = ?

f is an arrow function which takes a as an argument and returns the result of b ? c: d.

This should be rewritten like so:

/*eslint-env es6*/

var a = 1, b = 2, c = 3, d = 4;
var f = (a) => b ? c: d;

as-needed

Examples of incorrect code for this rule with the "as-needed" option:

/*eslint arrow-parens: ["error", "as-needed"]*/
/*eslint-env es6*/

(a) => {};
(a) => a;
(a) => {'\n'};
a.then((foo) => {});
a.then((foo) => a);
a((foo) => { if (true) {} });

Examples of correct code for this rule with the "as-needed" option:

/*eslint arrow-parens: ["error", "as-needed"]*/
/*eslint-env es6*/

() => {};
a => {};
a => a;
a => {'\n'};
a.then(foo => {});
a.then(foo => { if (true) {} });
(a, b, c) => a;
(a = 10) => a;
([a, b]) => a;
({a, b}) => a;

requireForBlockBody

Examples of incorrect code for the { "requireForBlockBody": true } option:

/*eslint arrow-parens: [2, "as-needed", { "requireForBlockBody": true }]*/
/*eslint-env es6*/

(a) => a;
a => {};
a => {'\n'};
a.map((x) => x * x);
a.map(x => {
  return x * x;
});
a.then(foo => {});

Examples of correct code for the { "requireForBlockBody": true } option:

/*eslint arrow-parens: [2, "as-needed", { "requireForBlockBody": true }]*/
/*eslint-env es6*/

(a) => {};
(a) => {'\n'};
a => ({});
() => {};
a => a;
a.then((foo) => {});
a.then((foo) => { if (true) {} });
a((foo) => { if (true) {} });
(a, b, c) => a;
(a = 10) => a;
([a, b]) => a;
({a, b}) => a;

Further Reading

• The "as-needed", { "requireForBlockBody": true } rule is directly inspired by the Airbnb JS Style Guide. Source: http://eslint.org/docs/rules/

Require CamelCase (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!

Rule Details

This rule looks for any underscores (_) located within the source code. It ignores leading and trailing underscores and only checks those in the middle of a variable name. If ESLint decides that the variable is a constant (all uppercase), then no warning will be thrown. Otherwise, a warning will be thrown. This rule only flags definitions and assignments but not function calls. In case of ES6 import statements, this rule only targets the name of the variable that will be imported into the local module scope.

Options

This rule has an object option:

• "properties": "always" (default) enforces camelcase style for property names
• "properties": "never" does not check property names
• "ignoreDestructuring": false (default) enforces camelcase style for destructured identifiers
• "ignoreDestructuring": true does not check destructured identifiers
• allow (string[]) list of properties to accept. Accept regex.

properties: "always"

Examples of incorrect code for this rule with the default { "properties": "always" } option:

/*eslint camelcase: "error"*/

import { no_camelcased } from "external-module"

var my_favorite_color = "#112C85";

function do_something() {
    // ...
}

obj.do_something = function() {
    // ...
};

function foo({ no_camelcased }) {
    // ...
};

function foo({ isCamelcased: no_camelcased }) {
    // ...
}

function foo({ no_camelcased = 'default value' }) {
    // ...
};

var obj = {
    my_pref: 1
};

var { category_id = 1 } = query;

var { foo: no_camelcased } = bar;

var { foo: bar_baz = 1 } = quz;

Examples of correct code for this rule with the default { "properties": "always" } option:

/*eslint camelcase: "error"*/

import { no_camelcased as camelCased } from "external-module";

var myFavoriteColor   = "#112C85";
var _myFavoriteColor  = "#112C85";
var myFavoriteColor_  = "#112C85";
var MY_FAVORITE_COLOR = "#112C85";
var foo = bar.baz_boom;
var foo = { qux: bar.baz_boom };

obj.do_something();
do_something();
new do_something();

var { category_id: category } = query;

function foo({ isCamelCased }) {
    // ...
};

function foo({ isCamelCased: isAlsoCamelCased }) {
    // ...
}

function foo({ isCamelCased = 'default value' }) {
    // ...
};

var { categoryId = 1 } = query;

var { foo: isCamelCased } = bar;

var { foo: isCamelCased = 1 } = quz;

properties: "never"

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

/*eslint camelcase: ["error", {properties: "never"}]*/

var obj = {
    my_pref: 1
};

ignoreDestructuring: false

Examples of incorrect code for this rule with the default { "ignoreDestructuring": false } option:

/*eslint camelcase: "error"*/

var { category_id } = query;

var { category_id = 1 } = query;

var { category_id: category_id } = query;

var { category_id: category_alias } = query;

var { category_id: categoryId, ...other_props } = query;

ignoreDestructuring: true

Examples of incorrect code for this rule with the { "ignoreDestructuring": true } option:

/*eslint camelcase: ["error", {ignoreDestructuring: true}]*/

var { category_id: category_alias } = query;

var { category_id, ...other_props } = query;

Examples of correct code for this rule with the { "ignoreDestructuring": true } option:

/*eslint camelcase: ["error", {ignoreDestructuring: true}]*/

var { category_id } = query;

var { category_id = 1 } = query;

var { category_id: category_id } = query;

allow

Examples of correct code for this rule with the allow option:

/*eslint camelcase: ["error", {allow: ["UNSAFE_componentWillMount"]}]*/

function UNSAFE_componentWillMount() {
    // ...
}

/*eslint camelcase: ["error", {allow: ["^UNSAFE_"]}]*/

function UNSAFE_componentWillMount() {
    // ...
}

function UNSAFE_componentWillMount() {
    // ...
}

When Not To Use It

If you have established coding standards using a different naming convention (separating words with underscores), turn this rule off. Source: http://eslint.org/docs/rules/

require or disallow newlines around variable declarations (one-var-declaration-per-line)

Some developers declare multiple var statements on the same line:

var foo, bar, baz;

Others prefer to declare one var per line.

var foo,
    bar,
    baz;

Keeping to one of these styles across a project's codebase can help with maintaining code consistency.

Rule Details

This rule enforces a consistent newlines around variable declarations. This rule ignores variable declarations inside for loop conditionals.

Options

This rule has a single string option:

• "initializations" (default) enforces a newline around variable initializations
• "always" enforces a newline around variable declarations

initializations

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

/*eslint one-var-declaration-per-line: ["error", "initializations"]*/
/*eslint-env es6*/

var a, b, c = 0;

let a,
    b = 0, c;

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

/*eslint one-var-declaration-per-line: ["error", "initializations"]*/
/*eslint-env es6*/

var a, b;

let a,
    b;

let a,
    b = 0;

always

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

/*eslint one-var-declaration-per-line: ["error", "always"]*/
/*eslint-env es6*/

var a, b;

let a, b = 0;

const a = 0, b = 0;

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

/*eslint one-var-declaration-per-line: ["error", "always"]*/
/*eslint-env es6*/

var a,
    b;

let a,
    b = 0;

Related Rules

• [one-var](one-var.md) Source: http://eslint.org/docs/rules/

require or disallow newlines around variable declarations (one-var-declaration-per-line)

Some developers declare multiple var statements on the same line:

var foo, bar, baz;

Others prefer to declare one var per line.

var foo,
    bar,
    baz;

Keeping to one of these styles across a project's codebase can help with maintaining code consistency.

Rule Details

This rule enforces a consistent newlines around variable declarations. This rule ignores variable declarations inside for loop conditionals.

Options

This rule has a single string option:

• "initializations" (default) enforces a newline around variable initializations
• "always" enforces a newline around variable declarations

initializations

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

/*eslint one-var-declaration-per-line: ["error", "initializations"]*/
/*eslint-env es6*/

var a, b, c = 0;

let a,
    b = 0, c;

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

/*eslint one-var-declaration-per-line: ["error", "initializations"]*/
/*eslint-env es6*/

var a, b;

let a,
    b;

let a,
    b = 0;

always

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

/*eslint one-var-declaration-per-line: ["error", "always"]*/
/*eslint-env es6*/

var a, b;

let a, b = 0;

const a = 0, b = 0;

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

/*eslint one-var-declaration-per-line: ["error", "always"]*/
/*eslint-env es6*/

var a,
    b;

let a,
    b = 0;

Related Rules

• [one-var](one-var.md) Source: http://eslint.org/docs/rules/

Require CamelCase (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!

Rule Details

This rule looks for any underscores (_) located within the source code. It ignores leading and trailing underscores and only checks those in the middle of a variable name. If ESLint decides that the variable is a constant (all uppercase), then no warning will be thrown. Otherwise, a warning will be thrown. This rule only flags definitions and assignments but not function calls. In case of ES6 import statements, this rule only targets the name of the variable that will be imported into the local module scope.

Options

This rule has an object option:

• "properties": "always" (default) enforces camelcase style for property names
• "properties": "never" does not check property names
• "ignoreDestructuring": false (default) enforces camelcase style for destructured identifiers
• "ignoreDestructuring": true does not check destructured identifiers
• allow (string[]) list of properties to accept. Accept regex.

properties: "always"

Examples of incorrect code for this rule with the default { "properties": "always" } option:

/*eslint camelcase: "error"*/

import { no_camelcased } from "external-module"

var my_favorite_color = "#112C85";

function do_something() {
    // ...
}

obj.do_something = function() {
    // ...
};

function foo({ no_camelcased }) {
    // ...
};

function foo({ isCamelcased: no_camelcased }) {
    // ...
}

function foo({ no_camelcased = 'default value' }) {
    // ...
};

var obj = {
    my_pref: 1
};

var { category_id = 1 } = query;

var { foo: no_camelcased } = bar;

var { foo: bar_baz = 1 } = quz;

Examples of correct code for this rule with the default { "properties": "always" } option:

/*eslint camelcase: "error"*/

import { no_camelcased as camelCased } from "external-module";

var myFavoriteColor   = "#112C85";
var _myFavoriteColor  = "#112C85";
var myFavoriteColor_  = "#112C85";
var MY_FAVORITE_COLOR = "#112C85";
var foo = bar.baz_boom;
var foo = { qux: bar.baz_boom };

obj.do_something();
do_something();
new do_something();

var { category_id: category } = query;

function foo({ isCamelCased }) {
    // ...
};

function foo({ isCamelCased: isAlsoCamelCased }) {
    // ...
}

function foo({ isCamelCased = 'default value' }) {
    // ...
};

var { categoryId = 1 } = query;

var { foo: isCamelCased } = bar;

var { foo: isCamelCased = 1 } = quz;

properties: "never"

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

/*eslint camelcase: ["error", {properties: "never"}]*/

var obj = {
    my_pref: 1
};

ignoreDestructuring: false

Examples of incorrect code for this rule with the default { "ignoreDestructuring": false } option:

/*eslint camelcase: "error"*/

var { category_id } = query;

var { category_id = 1 } = query;

var { category_id: category_id } = query;

var { category_id: category_alias } = query;

var { category_id: categoryId, ...other_props } = query;

ignoreDestructuring: true

Examples of incorrect code for this rule with the { "ignoreDestructuring": true } option:

/*eslint camelcase: ["error", {ignoreDestructuring: true}]*/

var { category_id: category_alias } = query;

var { category_id, ...other_props } = query;

Examples of correct code for this rule with the { "ignoreDestructuring": true } option:

/*eslint camelcase: ["error", {ignoreDestructuring: true}]*/

var { category_id } = query;

var { category_id = 1 } = query;

var { category_id: category_id } = query;

allow

Examples of correct code for this rule with the allow option:

/*eslint camelcase: ["error", {allow: ["UNSAFE_componentWillMount"]}]*/

function UNSAFE_componentWillMount() {
    // ...
}

/*eslint camelcase: ["error", {allow: ["^UNSAFE_"]}]*/

function UNSAFE_componentWillMount() {
    // ...
}

function UNSAFE_componentWillMount() {
    // ...
}

When Not To Use It

If you have established coding standards using a different naming convention (separating words with underscores), turn this rule off. Source: http://eslint.org/docs/rules/

require or disallow semicolons instead of ASI (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. For example, the following lines are both valid:

var name = "ESLint"
var website = "eslint.org";

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. For example, consider this code:

return
{
    name: "ESLint"
};

This may look like a return statement that returns an object literal, however, the JavaScript engine will interpret this code as:

return;
{
    name: "ESLint";
}

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](no-unreachable.md) rule will protect your code from such cases.

On the other side of the argument are those who say 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. For example, consider this code:

var globalCounter = { }

(function () {
    var n = 0
    globalCounter.increment = function () {
        return ++n
    }
})()

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](no-unexpected-multiline.md) 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.

Rule Details

This rule enforces consistent use of semicolons.

Options

This rule has two options, a string option and an object option.

String option:

• "always" (default) requires semicolons at the end of statements
• "never" disallows semicolons as the end of statements (except to disambiguate statements beginning with [, (, /, +, or -)

Object option (when "always"):

• "omitLastInOneLineBlock": true ignores the last semicolon in a block in which its braces (and therefore the content of the block) are in the same line

Object option (when "never"):

• "beforeStatementContinuationChars": "any" (default) ignores semicolons (or lacking semicolon) at the end of statements if the next line starts with [, (, /, +, or -.
• "beforeStatementContinuationChars": "always" requires semicolons at the end of statements if the next line starts with [, (, /, +, or -.
• "beforeStatementContinuationChars": "never" disallows semicolons as the end of statements if it doesn't make ASI hazard even if the next line starts with [, (, /, +, or -.

always

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

/*eslint semi: ["error", "always"]*/

var name = "ESLint"

object.method = function() {
    // ...
}

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

/*eslint semi: "error"*/

var name = "ESLint";

object.method = function() {
    // ...
};

never

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

/*eslint semi: ["error", "never"]*/

var name = "ESLint";

object.method = function() {
    // ...
};

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

/*eslint semi: ["error", "never"]*/

var name = "ESLint"

object.method = function() {
    // ...
}

var name = "ESLint"

;(function() {
    // ...
})()

import a from "a"
(function() {
    // ...
})()

import b from "b"
;(function() {
    // ...
})()

omitLastInOneLineBlock

Examples of additional correct code for this rule with the "always", { "omitLastInOneLineBlock": true } options:

/*eslint semi: ["error", "always", { "omitLastInOneLineBlock": true}] */

if (foo) { bar() }

if (foo) { bar(); baz() }

beforeStatementContinuationChars

Examples of additional incorrect code for this rule with the "never", { "beforeStatementContinuationChars": "always" } options:

/*eslint semi: ["error", "never", { "beforeStatementContinuationChars": "always"}] */
import a from "a"

(function() {
    // ...
})()

Examples of additional incorrect code for this rule with the "never", { "beforeStatementContinuationChars": "never" } options:

/*eslint semi: ["error", "never", { "beforeStatementContinuationChars": "never"}] */
import a from "a"

;(function() {
    // ...
})()

When Not To Use It

If you do not want to enforce semicolon usage (or omission) in any particular way, then you can turn this rule off.

Further Reading

• An Open Letter to JavaScript Leaders Regarding Semicolons
• JavaScript Semicolon Insertion

Related Rules

• [no-extra-semi](no-extra-semi.md)
• [no-unexpected-multiline](no-unexpected-multiline.md)
• [semi-spacing](semi-spacing.md) Source: http://eslint.org/docs/rules/

Require parens in arrow function arguments (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.

Rule Details

This rule enforces parentheses around arrow function parameters regardless of arity. For example:

/*eslint-env es6*/

// Bad
a => {}

// Good
(a) => {}

Following this style will help you find arrow functions (=>) which may be mistakenly included in a condition when a comparison such as >= was the intent.

/*eslint-env es6*/

// Bad
if (a => 2) {
}

// Good
if (a >= 2) {
}

The rule can also be configured to discourage the use of parens when they are not required:

/*eslint-env es6*/

// Bad
(a) => {}

// Good
a => {}

Options

This rule has a string option and an object one.

String options are:

• "always" (default) requires parens around arguments in all cases.
• "as-needed" allows omitting parens when there is only one argument.

Object properties for variants of the "as-needed" option:

• "requireForBlockBody": true modifies the as-needed rule in order to require parens if the function body is in an instructions block (surrounded by braces).

always

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

/*eslint arrow-parens: ["error", "always"]*/
/*eslint-env es6*/

a => {};
a => a;
a => {'\n'};
a.then(foo => {});
a.then(foo => a);
a(foo => { if (true) {} });

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

/*eslint arrow-parens: ["error", "always"]*/
/*eslint-env es6*/

() => {};
(a) => {};
(a) => a;
(a) => {'\n'}
a.then((foo) => {});
a.then((foo) => { if (true) {} });

If Statements

One of benefits of this option is that it prevents the incorrect use of arrow functions in conditionals:

/*eslint-env es6*/

var a = 1;
var b = 2;
// ...
if (a => b) {
 console.log('bigger');
} else {
 console.log('smaller');
}
// outputs 'bigger', not smaller as expected

The contents of the if statement is an arrow function, not a comparison.

If the arrow function is intentional, it should be wrapped in parens to remove ambiguity.

/*eslint-env es6*/

var a = 1;
var b = 0;
// ...
if ((a) => b) {
 console.log('truthy value returned');
} else {
 console.log('falsey value returned');
}
// outputs 'truthy value returned'

The following is another example of this behavior:

/*eslint-env es6*/

var a = 1, b = 2, c = 3, d = 4;
var f = a => b ? c: d;
// f = ?

f is an arrow function which takes a as an argument and returns the result of b ? c: d.

This should be rewritten like so:

/*eslint-env es6*/

var a = 1, b = 2, c = 3, d = 4;
var f = (a) => b ? c: d;

as-needed

Examples of incorrect code for this rule with the "as-needed" option:

/*eslint arrow-parens: ["error", "as-needed"]*/
/*eslint-env es6*/

(a) => {};
(a) => a;
(a) => {'\n'};
a.then((foo) => {});
a.then((foo) => a);
a((foo) => { if (true) {} });

Examples of correct code for this rule with the "as-needed" option:

/*eslint arrow-parens: ["error", "as-needed"]*/
/*eslint-env es6*/

() => {};
a => {};
a => a;
a => {'\n'};
a.then(foo => {});
a.then(foo => { if (true) {} });
(a, b, c) => a;
(a = 10) => a;
([a, b]) => a;
({a, b}) => a;

requireForBlockBody

Examples of incorrect code for the { "requireForBlockBody": true } option:

/*eslint arrow-parens: [2, "as-needed", { "requireForBlockBody": true }]*/
/*eslint-env es6*/

(a) => a;
a => {};
a => {'\n'};
a.map((x) => x * x);
a.map(x => {
  return x * x;
});
a.then(foo => {});

Examples of correct code for the { "requireForBlockBody": true } option:

/*eslint arrow-parens: [2, "as-needed", { "requireForBlockBody": true }]*/
/*eslint-env es6*/

(a) => {};
(a) => {'\n'};
a => ({});
() => {};
a => a;
a.then((foo) => {});
a.then((foo) => { if (true) {} });
a((foo) => { if (true) {} });
(a, b, c) => a;
(a = 10) => a;
([a, b]) => a;
({a, b}) => a;

Further Reading

• The "as-needed", { "requireForBlockBody": true } rule is directly inspired by the Airbnb JS Style Guide. Source: http://eslint.org/docs/rules/

Require Object Literal Shorthand Syntax (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.

Here are a few common examples using the ES5 syntax:

// properties
var foo = {
    x: x,
    y: y,
    z: z,
};

// methods
var foo = {
    a: function() {},
    b: function() {}
};

Now here are ES6 equivalents:

/*eslint-env es6*/

// properties
var foo = {x, y, z};

// methods
var foo = {
    a() {},
    b() {}
};

Rule Details

This rule enforces the use of the shorthand syntax. This applies to all methods (including generators) defined in object literals and any properties defined where the key name matches name of the assigned variable.

Each of the following properties would warn:

/*eslint object-shorthand: "error"*/
/*eslint-env es6*/

var foo = {
    w: function() {},
    x: function *() {},
    [y]: function() {},
    z: z
};

In that case the expected syntax would have been:

/*eslint object-shorthand: "error"*/
/*eslint-env es6*/

var foo = {
    w() {},
    *x() {},
    [y]() {},
    z
};

This rule does not flag arrow functions inside of object literals. The following will not warn:

/*eslint object-shorthand: "error"*/
/*eslint-env es6*/

var foo = {
    x: (y) => y
};

See Also:

• no-useless-rename which disallows renaming import, export, and destructured assignments to the same name.

Options

The rule takes an option which specifies when it should be applied. It can be set to one of the following values:

• "always" (default) expects that the shorthand will be used whenever possible.
• "methods" ensures the method shorthand is used (also applies to generators).
• "properties" ensures the property shorthand is used (where the key and variable name match).
• "never" ensures that no property or method shorthand is used in any object literal.
• "consistent" ensures that either all shorthand or all long-form will be used in an object literal.
• "consistent-as-needed" ensures that either all shorthand or all long-form will be used in an object literal, but ensures all shorthand whenever possible.

You can set the option in configuration like this:

{
    "object-shorthand": ["error", "always"]
}

Additionally, the rule takes an optional object configuration:

• "avoidQuotes": true indicates that long-form syntax is preferred whenever the object key is a string literal (default: false). Note that this option can only be enabled when the string option is set to "always", "methods", or "properties".
• "ignoreConstructors": true can be used to prevent the rule from reporting errors for constructor functions. (By default, the rule treats constructors the same way as other functions.) Note that this option can only be enabled when the string option is set to "always" or "methods".
• "avoidExplicitReturnArrows": true indicates that methods are preferred over explicit-return arrow functions for function properties. (By default, the rule allows either of these.) Note that this option can only be enabled when the string option is set to "always" or "methods".

avoidQuotes

{
    "object-shorthand": ["error", "always", { "avoidQuotes": true }]
}

Example of incorrect code for this rule with the "always", { "avoidQuotes": true } option:

/*eslint object-shorthand: ["error", "always", { "avoidQuotes": true }]*/
/*eslint-env es6*/

var foo = {
    "bar-baz"() {}
};

Example of correct code for this rule with the "always", { "avoidQuotes": true } option:

/*eslint object-shorthand: ["error", "always", { "avoidQuotes": true }]*/
/*eslint-env es6*/

var foo = {
    "bar-baz": function() {},
    "qux": qux
};

ignoreConstructors

{
    "object-shorthand": ["error", "always", { "ignoreConstructors": true }]
}

Example of correct code for this rule with the "always", { "ignoreConstructors": true } option:

/*eslint object-shorthand: ["error", "always", { "ignoreConstructors": true }]*/
/*eslint-env es6*/

var foo = {
    ConstructorFunction: function() {}
};

avoidExplicitReturnArrows

{
    "object-shorthand": ["error", "always", { "avoidExplicitReturnArrows": true }]
}

Example of incorrect code for this rule with the "always", { "avoidExplicitReturnArrows": true } option:

/*eslint object-shorthand: ["error", "always", { "avoidExplicitReturnArrows": true }]*/
/*eslint-env es6*/

var foo = {
  foo: (bar, baz) => {
    return bar + baz;
  },

  qux: (foobar) => {
    return foobar * 2;
  }
};

Example of correct code for this rule with the "always", { "avoidExplicitReturnArrows": true } option:

/*eslint object-shorthand: ["error", "always", { "avoidExplicitReturnArrows": true }]*/
/*eslint-env es6*/

var foo = {
  foo(bar, baz) {
    return bar + baz;
  },

  qux: foobar => foobar * 2
};

Example of incorrect code for this rule with the "consistent" option:

/*eslint object-shorthand: [2, "consistent"]*/
/*eslint-env es6*/

var foo = {
    a,
    b: "foo",
};

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

/*eslint object-shorthand: [2, "consistent"]*/
/*eslint-env es6*/

var foo = {
    a: a,
    b: "foo"
};

var bar = {
    a,
    b,
};

Example of incorrect code with the "consistent-as-needed" option, which is very similar to "consistent":

/*eslint object-shorthand: [2, "consistent-as-needed"]*/
/*eslint-env es6*/

var foo = {
    a: a,
    b: b,
};

When Not To Use It

Anyone not yet in an ES6 environment would not want to apply this rule. Others may find the terseness of the shorthand syntax harder to read and may not want to encourage it with this rule.

Further Reading

Object initializer - MDN Source: http://eslint.org/docs/rules/

require or disallow semicolons instead of ASI (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. For example, the following lines are both valid:

var name = "ESLint"
var website = "eslint.org";

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. For example, consider this code:

return
{
    name: "ESLint"
};

This may look like a return statement that returns an object literal, however, the JavaScript engine will interpret this code as:

return;
{
    name: "ESLint";
}

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](no-unreachable.md) rule will protect your code from such cases.

On the other side of the argument are those who say 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. For example, consider this code:

var globalCounter = { }

(function () {
    var n = 0
    globalCounter.increment = function () {
        return ++n
    }
})()

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](no-unexpected-multiline.md) 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.

Rule Details

This rule enforces consistent use of semicolons.

Options

This rule has two options, a string option and an object option.

String option:

• "always" (default) requires semicolons at the end of statements
• "never" disallows semicolons as the end of statements (except to disambiguate statements beginning with [, (, /, +, or -)

Object option (when "always"):

• "omitLastInOneLineBlock": true ignores the last semicolon in a block in which its braces (and therefore the content of the block) are in the same line

Object option (when "never"):

• "beforeStatementContinuationChars": "any" (default) ignores semicolons (or lacking semicolon) at the end of statements if the next line starts with [, (, /, +, or -.
• "beforeStatementContinuationChars": "always" requires semicolons at the end of statements if the next line starts with [, (, /, +, or -.
• "beforeStatementContinuationChars": "never" disallows semicolons as the end of statements if it doesn't make ASI hazard even if the next line starts with [, (, /, +, or -.

always

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

/*eslint semi: ["error", "always"]*/

var name = "ESLint"

object.method = function() {
    // ...
}

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

/*eslint semi: "error"*/

var name = "ESLint";

object.method = function() {
    // ...
};

never

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

/*eslint semi: ["error", "never"]*/

var name = "ESLint";

object.method = function() {
    // ...
};

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

/*eslint semi: ["error", "never"]*/

var name = "ESLint"

object.method = function() {
    // ...
}

var name = "ESLint"

;(function() {
    // ...
})()

import a from "a"
(function() {
    // ...
})()

import b from "b"
;(function() {
    // ...
})()

omitLastInOneLineBlock

Examples of additional correct code for this rule with the "always", { "omitLastInOneLineBlock": true } options:

/*eslint semi: ["error", "always", { "omitLastInOneLineBlock": true}] */

if (foo) { bar() }

if (foo) { bar(); baz() }

beforeStatementContinuationChars

Examples of additional incorrect code for this rule with the "never", { "beforeStatementContinuationChars": "always" } options:

/*eslint semi: ["error", "never", { "beforeStatementContinuationChars": "always"}] */
import a from "a"

(function() {
    // ...
})()

Examples of additional incorrect code for this rule with the "never", { "beforeStatementContinuationChars": "never" } options:

/*eslint semi: ["error", "never", { "beforeStatementContinuationChars": "never"}] */
import a from "a"

;(function() {
    // ...
})()

When Not To Use It

If you do not want to enforce semicolon usage (or omission) in any particular way, then you can turn this rule off.

Further Reading

• An Open Letter to JavaScript Leaders Regarding Semicolons
• JavaScript Semicolon Insertion

Related Rules

• [no-extra-semi](no-extra-semi.md)
• [no-unexpected-multiline](no-unexpected-multiline.md)
• [semi-spacing](semi-spacing.md) Source: http://eslint.org/docs/rules/

require let or const instead of var (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 such as:

var count = people.length;
var enoughFood = count > sandwiches.length;

if (enoughFood) {
    var count = sandwiches.length; // accidentally overriding the count variable
    console.log("We have " + count + " sandwiches for everyone. Plenty for all!");
}

// our count variable is no longer accurate
console.log("We have " + count + " people and " + sandwiches.length + " sandwiches!");

Rule Details

This rule is aimed at discouraging the use of var and encouraging the use of const or let instead.

Examples

Examples of incorrect code for this rule:

/*eslint no-var: "error"*/

var x = "y";
var CONFIG = {};

Examples of correct code for this rule:

/*eslint no-var: "error"*/
/*eslint-env es6*/

let x = "y";
const CONFIG = {};

When Not To Use It

In addition to non-ES6 environments, existing JavaScript projects that are beginning to introduce ES6 into their codebase may not want to apply this rule if the cost of migrating from var to let is too costly. Source: http://eslint.org/docs/rules/

Require CamelCase (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!

Rule Details

This rule looks for any underscores (_) located within the source code. It ignores leading and trailing underscores and only checks those in the middle of a variable name. If ESLint decides that the variable is a constant (all uppercase), then no warning will be thrown. Otherwise, a warning will be thrown. This rule only flags definitions and assignments but not function calls. In case of ES6 import statements, this rule only targets the name of the variable that will be imported into the local module scope.

Options

This rule has an object option:

• "properties": "always" (default) enforces camelcase style for property names
• "properties": "never" does not check property names
• "ignoreDestructuring": false (default) enforces camelcase style for destructured identifiers
• "ignoreDestructuring": true does not check destructured identifiers
• allow (string[]) list of properties to accept. Accept regex.

properties: "always"

Examples of incorrect code for this rule with the default { "properties": "always" } option:

/*eslint camelcase: "error"*/

import { no_camelcased } from "external-module"

var my_favorite_color = "#112C85";

function do_something() {
    // ...
}

obj.do_something = function() {
    // ...
};

function foo({ no_camelcased }) {
    // ...
};

function foo({ isCamelcased: no_camelcased }) {
    // ...
}

function foo({ no_camelcased = 'default value' }) {
    // ...
};

var obj = {
    my_pref: 1
};

var { category_id = 1 } = query;

var { foo: no_camelcased } = bar;

var { foo: bar_baz = 1 } = quz;

Examples of correct code for this rule with the default { "properties": "always" } option:

/*eslint camelcase: "error"*/

import { no_camelcased as camelCased } from "external-module";

var myFavoriteColor   = "#112C85";
var _myFavoriteColor  = "#112C85";
var myFavoriteColor_  = "#112C85";
var MY_FAVORITE_COLOR = "#112C85";
var foo = bar.baz_boom;
var foo = { qux: bar.baz_boom };

obj.do_something();
do_something();
new do_something();

var { category_id: category } = query;

function foo({ isCamelCased }) {
    // ...
};

function foo({ isCamelCased: isAlsoCamelCased }) {
    // ...
}

function foo({ isCamelCased = 'default value' }) {
    // ...
};

var { categoryId = 1 } = query;

var { foo: isCamelCased } = bar;

var { foo: isCamelCased = 1 } = quz;

properties: "never"

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

/*eslint camelcase: ["error", {properties: "never"}]*/

var obj = {
    my_pref: 1
};

ignoreDestructuring: false

Examples of incorrect code for this rule with the default { "ignoreDestructuring": false } option:

/*eslint camelcase: "error"*/

var { category_id } = query;

var { category_id = 1 } = query;

var { category_id: category_id } = query;

var { category_id: category_alias } = query;

var { category_id: categoryId, ...other_props } = query;

ignoreDestructuring: true

Examples of incorrect code for this rule with the { "ignoreDestructuring": true } option:

/*eslint camelcase: ["error", {ignoreDestructuring: true}]*/

var { category_id: category_alias } = query;

var { category_id, ...other_props } = query;

Examples of correct code for this rule with the { "ignoreDestructuring": true } option:

/*eslint camelcase: ["error", {ignoreDestructuring: true}]*/

var { category_id } = query;

var { category_id = 1 } = query;

var { category_id: category_id } = query;

allow

Examples of correct code for this rule with the allow option:

/*eslint camelcase: ["error", {allow: ["UNSAFE_componentWillMount"]}]*/

function UNSAFE_componentWillMount() {
    // ...
}

/*eslint camelcase: ["error", {allow: ["^UNSAFE_"]}]*/

function UNSAFE_componentWillMount() {
    // ...
}

function UNSAFE_componentWillMount() {
    // ...
}

When Not To Use It

If you have established coding standards using a different naming convention (separating words with underscores), turn this rule off. Source: http://eslint.org/docs/rules/

Require Variable Declarations to be at the top of their scope (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.

Rule Details

This rule aims to keep all variable declarations in the leading series of statements. Allowing multiple declarations helps promote maintainability and is thus allowed.

Examples of incorrect code for this rule:

/*eslint vars-on-top: "error"*/

// Variable declarations in a block:
function doSomething() {
    var first;
    if (true) {
        first = true;
    }
    var second;
}

// Variable declaration in for initializer:
function doSomething() {
    for (var i=0; i<10; i++) {}
}

/*eslint vars-on-top: "error"*/

// Variables after other statements:
f();
var a;

Examples of correct code for this rule:

/*eslint vars-on-top: "error"*/

function doSomething() {
    var first;
    var second; //multiple declarations are allowed at the top
    if (true) {
        first = true;
    }
}

function doSomething() {
    var i;
    for (i=0; i<10; i++) {}
}

/*eslint vars-on-top: "error"*/

var a;
f();

/*eslint vars-on-top: "error"*/

// Directives may precede variable declarations.
"use strict";
var a;
f();

// Comments can describe variables.
function doSomething() {
    // this is the first var.
    var first;
    // this is the second var.
    var second
}

Further Reading

• JavaScript Scoping and Hoisting
• var Hoisting
• A criticism of the Single Var Pattern in JavaScript, and a simple alternative
• Multiple var statements in JavaScript, not superfluous Source: http://eslint.org/docs/rules/

Require CamelCase (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!

Rule Details

This rule looks for any underscores (_) located within the source code. It ignores leading and trailing underscores and only checks those in the middle of a variable name. If ESLint decides that the variable is a constant (all uppercase), then no warning will be thrown. Otherwise, a warning will be thrown. This rule only flags definitions and assignments but not function calls. In case of ES6 import statements, this rule only targets the name of the variable that will be imported into the local module scope.

Options

This rule has an object option:

• "properties": "always" (default) enforces camelcase style for property names
• "properties": "never" does not check property names
• "ignoreDestructuring": false (default) enforces camelcase style for destructured identifiers
• "ignoreDestructuring": true does not check destructured identifiers
• allow (string[]) list of properties to accept. Accept regex.

properties: "always"

Examples of incorrect code for this rule with the default { "properties": "always" } option:

/*eslint camelcase: "error"*/

import { no_camelcased } from "external-module"

var my_favorite_color = "#112C85";

function do_something() {
    // ...
}

obj.do_something = function() {
    // ...
};

function foo({ no_camelcased }) {
    // ...
};

function foo({ isCamelcased: no_camelcased }) {
    // ...
}

function foo({ no_camelcased = 'default value' }) {
    // ...
};

var obj = {
    my_pref: 1
};

var { category_id = 1 } = query;

var { foo: no_camelcased } = bar;

var { foo: bar_baz = 1 } = quz;

Examples of correct code for this rule with the default { "properties": "always" } option:

/*eslint camelcase: "error"*/

import { no_camelcased as camelCased } from "external-module";

var myFavoriteColor   = "#112C85";
var _myFavoriteColor  = "#112C85";
var myFavoriteColor_  = "#112C85";
var MY_FAVORITE_COLOR = "#112C85";
var foo = bar.baz_boom;
var foo = { qux: bar.baz_boom };

obj.do_something();
do_something();
new do_something();

var { category_id: category } = query;

function foo({ isCamelCased }) {
    // ...
};

function foo({ isCamelCased: isAlsoCamelCased }) {
    // ...
}

function foo({ isCamelCased = 'default value' }) {
    // ...
};

var { categoryId = 1 } = query;

var { foo: isCamelCased } = bar;

var { foo: isCamelCased = 1 } = quz;

properties: "never"

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

/*eslint camelcase: ["error", {properties: "never"}]*/

var obj = {
    my_pref: 1
};

ignoreDestructuring: false

Examples of incorrect code for this rule with the default { "ignoreDestructuring": false } option:

/*eslint camelcase: "error"*/

var { category_id } = query;

var { category_id = 1 } = query;

var { category_id: category_id } = query;

var { category_id: category_alias } = query;

var { category_id: categoryId, ...other_props } = query;

ignoreDestructuring: true

Examples of incorrect code for this rule with the { "ignoreDestructuring": true } option:

/*eslint camelcase: ["error", {ignoreDestructuring: true}]*/

var { category_id: category_alias } = query;

var { category_id, ...other_props } = query;

Examples of correct code for this rule with the { "ignoreDestructuring": true } option:

/*eslint camelcase: ["error", {ignoreDestructuring: true}]*/

var { category_id } = query;

var { category_id = 1 } = query;

var { category_id: category_id } = query;

allow

Examples of correct code for this rule with the allow option:

/*eslint camelcase: ["error", {allow: ["UNSAFE_componentWillMount"]}]*/

function UNSAFE_componentWillMount() {
    // ...
}

/*eslint camelcase: ["error", {allow: ["^UNSAFE_"]}]*/

function UNSAFE_componentWillMount() {
    // ...
}

function UNSAFE_componentWillMount() {
    // ...
}

When Not To Use It

If you have established coding standards using a different naming convention (separating words with underscores), turn this rule off. Source: http://eslint.org/docs/rules/

require let or const instead of var (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 such as:

var count = people.length;
var enoughFood = count > sandwiches.length;

if (enoughFood) {
    var count = sandwiches.length; // accidentally overriding the count variable
    console.log("We have " + count + " sandwiches for everyone. Plenty for all!");
}

// our count variable is no longer accurate
console.log("We have " + count + " people and " + sandwiches.length + " sandwiches!");

Rule Details

This rule is aimed at discouraging the use of var and encouraging the use of const or let instead.

Examples

Examples of incorrect code for this rule:

/*eslint no-var: "error"*/

var x = "y";
var CONFIG = {};

Examples of correct code for this rule:

/*eslint no-var: "error"*/
/*eslint-env es6*/

let x = "y";
const CONFIG = {};

When Not To Use It

In addition to non-ES6 environments, existing JavaScript projects that are beginning to introduce ES6 into their codebase may not want to apply this rule if the cost of migrating from var to let is too costly. Source: http://eslint.org/docs/rules/

Require CamelCase (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!

Rule Details

This rule looks for any underscores (_) located within the source code. It ignores leading and trailing underscores and only checks those in the middle of a variable name. If ESLint decides that the variable is a constant (all uppercase), then no warning will be thrown. Otherwise, a warning will be thrown. This rule only flags definitions and assignments but not function calls. In case of ES6 import statements, this rule only targets the name of the variable that will be imported into the local module scope.

Options

This rule has an object option:

• "properties": "always" (default) enforces camelcase style for property names
• "properties": "never" does not check property names
• "ignoreDestructuring": false (default) enforces camelcase style for destructured identifiers
• "ignoreDestructuring": true does not check destructured identifiers
• allow (string[]) list of properties to accept. Accept regex.

properties: "always"

Examples of incorrect code for this rule with the default { "properties": "always" } option:

/*eslint camelcase: "error"*/

import { no_camelcased } from "external-module"

var my_favorite_color = "#112C85";

function do_something() {
    // ...
}

obj.do_something = function() {
    // ...
};

function foo({ no_camelcased }) {
    // ...
};

function foo({ isCamelcased: no_camelcased }) {
    // ...
}

function foo({ no_camelcased = 'default value' }) {
    // ...
};

var obj = {
    my_pref: 1
};

var { category_id = 1 } = query;

var { foo: no_camelcased } = bar;

var { foo: bar_baz = 1 } = quz;

Examples of correct code for this rule with the default { "properties": "always" } option:

/*eslint camelcase: "error"*/

import { no_camelcased as camelCased } from "external-module";

var myFavoriteColor   = "#112C85";
var _myFavoriteColor  = "#112C85";
var myFavoriteColor_  = "#112C85";
var MY_FAVORITE_COLOR = "#112C85";
var foo = bar.baz_boom;
var foo = { qux: bar.baz_boom };

obj.do_something();
do_something();
new do_something();

var { category_id: category } = query;

function foo({ isCamelCased }) {
    // ...
};

function foo({ isCamelCased: isAlsoCamelCased }) {
    // ...
}

function foo({ isCamelCased = 'default value' }) {
    // ...
};

var { categoryId = 1 } = query;

var { foo: isCamelCased } = bar;

var { foo: isCamelCased = 1 } = quz;

properties: "never"

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

/*eslint camelcase: ["error", {properties: "never"}]*/

var obj = {
    my_pref: 1
};

ignoreDestructuring: false

Examples of incorrect code for this rule with the default { "ignoreDestructuring": false } option:

/*eslint camelcase: "error"*/

var { category_id } = query;

var { category_id = 1 } = query;

var { category_id: category_id } = query;

var { category_id: category_alias } = query;

var { category_id: categoryId, ...other_props } = query;

ignoreDestructuring: true

Examples of incorrect code for this rule with the { "ignoreDestructuring": true } option:

/*eslint camelcase: ["error", {ignoreDestructuring: true}]*/

var { category_id: category_alias } = query;

var { category_id, ...other_props } = query;

Examples of correct code for this rule with the { "ignoreDestructuring": true } option:

/*eslint camelcase: ["error", {ignoreDestructuring: true}]*/

var { category_id } = query;

var { category_id = 1 } = query;

var { category_id: category_id } = query;

allow

Examples of correct code for this rule with the allow option:

/*eslint camelcase: ["error", {allow: ["UNSAFE_componentWillMount"]}]*/

function UNSAFE_componentWillMount() {
    // ...
}

/*eslint camelcase: ["error", {allow: ["^UNSAFE_"]}]*/

function UNSAFE_componentWillMount() {
    // ...
}

function UNSAFE_componentWillMount() {
    // ...
}

When Not To Use It

If you have established coding standards using a different naming convention (separating words with underscores), turn this rule off. Source: http://eslint.org/docs/rules/

Require CamelCase (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!

Rule Details

This rule looks for any underscores (_) located within the source code. It ignores leading and trailing underscores and only checks those in the middle of a variable name. If ESLint decides that the variable is a constant (all uppercase), then no warning will be thrown. Otherwise, a warning will be thrown. This rule only flags definitions and assignments but not function calls. In case of ES6 import statements, this rule only targets the name of the variable that will be imported into the local module scope.

Options

This rule has an object option:

• "properties": "always" (default) enforces camelcase style for property names
• "properties": "never" does not check property names
• "ignoreDestructuring": false (default) enforces camelcase style for destructured identifiers
• "ignoreDestructuring": true does not check destructured identifiers
• allow (string[]) list of properties to accept. Accept regex.

properties: "always"

Examples of incorrect code for this rule with the default { "properties": "always" } option:

/*eslint camelcase: "error"*/

import { no_camelcased } from "external-module"

var my_favorite_color = "#112C85";

function do_something() {
    // ...
}

obj.do_something = function() {
    // ...
};

function foo({ no_camelcased }) {
    // ...
};

function foo({ isCamelcased: no_camelcased }) {
    // ...
}

function foo({ no_camelcased = 'default value' }) {
    // ...
};

var obj = {
    my_pref: 1
};

var { category_id = 1 } = query;

var { foo: no_camelcased } = bar;

var { foo: bar_baz = 1 } = quz;

Examples of correct code for this rule with the default { "properties": "always" } option:

/*eslint camelcase: "error"*/

import { no_camelcased as camelCased } from "external-module";

var myFavoriteColor   = "#112C85";
var _myFavoriteColor  = "#112C85";
var myFavoriteColor_  = "#112C85";
var MY_FAVORITE_COLOR = "#112C85";
var foo = bar.baz_boom;
var foo = { qux: bar.baz_boom };

obj.do_something();
do_something();
new do_something();

var { category_id: category } = query;

function foo({ isCamelCased }) {
    // ...
};

function foo({ isCamelCased: isAlsoCamelCased }) {
    // ...
}

function foo({ isCamelCased = 'default value' }) {
    // ...
};

var { categoryId = 1 } = query;

var { foo: isCamelCased } = bar;

var { foo: isCamelCased = 1 } = quz;

properties: "never"

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

/*eslint camelcase: ["error", {properties: "never"}]*/

var obj = {
    my_pref: 1
};

ignoreDestructuring: false

Examples of incorrect code for this rule with the default { "ignoreDestructuring": false } option:

/*eslint camelcase: "error"*/

var { category_id } = query;

var { category_id = 1 } = query;

var { category_id: category_id } = query;

var { category_id: category_alias } = query;

var { category_id: categoryId, ...other_props } = query;

ignoreDestructuring: true

Examples of incorrect code for this rule with the { "ignoreDestructuring": true } option:

/*eslint camelcase: ["error", {ignoreDestructuring: true}]*/

var { category_id: category_alias } = query;

var { category_id, ...other_props } = query;

Examples of correct code for this rule with the { "ignoreDestructuring": true } option:

/*eslint camelcase: ["error", {ignoreDestructuring: true}]*/

var { category_id } = query;

var { category_id = 1 } = query;

var { category_id: category_id } = query;

allow

Examples of correct code for this rule with the allow option:

/*eslint camelcase: ["error", {allow: ["UNSAFE_componentWillMount"]}]*/

function UNSAFE_componentWillMount() {
    // ...
}

/*eslint camelcase: ["error", {allow: ["^UNSAFE_"]}]*/

function UNSAFE_componentWillMount() {
    // ...
}

function UNSAFE_componentWillMount() {
    // ...
}

When Not To Use It

If you have established coding standards using a different naming convention (separating words with underscores), turn this rule off. Source: http://eslint.org/docs/rules/

Require CamelCase (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!

Rule Details

This rule looks for any underscores (_) located within the source code. It ignores leading and trailing underscores and only checks those in the middle of a variable name. If ESLint decides that the variable is a constant (all uppercase), then no warning will be thrown. Otherwise, a warning will be thrown. This rule only flags definitions and assignments but not function calls. In case of ES6 import statements, this rule only targets the name of the variable that will be imported into the local module scope.

Options

This rule has an object option:

• "properties": "always" (default) enforces camelcase style for property names
• "properties": "never" does not check property names
• "ignoreDestructuring": false (default) enforces camelcase style for destructured identifiers
• "ignoreDestructuring": true does not check destructured identifiers
• allow (string[]) list of properties to accept. Accept regex.

properties: "always"

Examples of incorrect code for this rule with the default { "properties": "always" } option:

/*eslint camelcase: "error"*/

import { no_camelcased } from "external-module"

var my_favorite_color = "#112C85";

function do_something() {
    // ...
}

obj.do_something = function() {
    // ...
};

function foo({ no_camelcased }) {
    // ...
};

function foo({ isCamelcased: no_camelcased }) {
    // ...
}

function foo({ no_camelcased = 'default value' }) {
    // ...
};

var obj = {
    my_pref: 1
};

var { category_id = 1 } = query;

var { foo: no_camelcased } = bar;

var { foo: bar_baz = 1 } = quz;

Examples of correct code for this rule with the default { "properties": "always" } option:

/*eslint camelcase: "error"*/

import { no_camelcased as camelCased } from "external-module";

var myFavoriteColor   = "#112C85";
var _myFavoriteColor  = "#112C85";
var myFavoriteColor_  = "#112C85";
var MY_FAVORITE_COLOR = "#112C85";
var foo = bar.baz_boom;
var foo = { qux: bar.baz_boom };

obj.do_something();
do_something();
new do_something();

var { category_id: category } = query;

function foo({ isCamelCased }) {
    // ...
};

function foo({ isCamelCased: isAlsoCamelCased }) {
    // ...
}

function foo({ isCamelCased = 'default value' }) {
    // ...
};

var { categoryId = 1 } = query;

var { foo: isCamelCased } = bar;

var { foo: isCamelCased = 1 } = quz;

properties: "never"

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

/*eslint camelcase: ["error", {properties: "never"}]*/

var obj = {
    my_pref: 1
};

ignoreDestructuring: false

Examples of incorrect code for this rule with the default { "ignoreDestructuring": false } option:

/*eslint camelcase: "error"*/

var { category_id } = query;

var { category_id = 1 } = query;

var { category_id: category_id } = query;

var { category_id: category_alias } = query;

var { category_id: categoryId, ...other_props } = query;

ignoreDestructuring: true

Examples of incorrect code for this rule with the { "ignoreDestructuring": true } option:

/*eslint camelcase: ["error", {ignoreDestructuring: true}]*/

var { category_id: category_alias } = query;

var { category_id, ...other_props } = query;

Examples of correct code for this rule with the { "ignoreDestructuring": true } option:

/*eslint camelcase: ["error", {ignoreDestructuring: true}]*/

var { category_id } = query;

var { category_id = 1 } = query;

var { category_id: category_id } = query;

allow

Examples of correct code for this rule with the allow option:

/*eslint camelcase: ["error", {allow: ["UNSAFE_componentWillMount"]}]*/

function UNSAFE_componentWillMount() {
    // ...
}

/*eslint camelcase: ["error", {allow: ["^UNSAFE_"]}]*/

function UNSAFE_componentWillMount() {
    // ...
}

function UNSAFE_componentWillMount() {
    // ...
}

When Not To Use It

If you have established coding standards using a different naming convention (separating words with underscores), turn this rule off. Source: http://eslint.org/docs/rules/

Require === and !== (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:

• [] == false
• [] == ![]
• 3 == "03"

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

Rule Details

This rule is aimed at eliminating the type-unsafe equality operators.

Examples of incorrect code for this rule:

/*eslint eqeqeq: "error"*/

if (x == 42) { }

if ("" == text) { }

if (obj.getStuff() != undefined) { }

The --fix option on the command line automatically fixes some problems reported by this rule. A problem is only fixed if one of the operands is a typeof expression, or if both operands are literals with the same type.

Options

always

The "always" option (default) enforces the use of === and !== in every situation (except when you opt-in to more specific handling of null [see below]).

Examples of incorrect code for the "always" option:

/*eslint eqeqeq: ["error", "always"]*/

a == b
foo == true
bananas != 1
value == undefined
typeof foo == 'undefined'
'hello' != 'world'
0 == 0
true == true
foo == null

Examples of correct code for the "always" option:

/*eslint eqeqeq: ["error", "always"]*/

a === b
foo === true
bananas !== 1
value === undefined
typeof foo === 'undefined'
'hello' !== 'world'
0 === 0
true === true
foo === null

This rule optionally takes a second argument, which should be an object with the following supported properties:

• "null": Customize how this rule treats null literals. Possible values:
  • always (default) - Always use === or !==.
  • never - Never use === or !== with null.
  • ignore - Do not apply this rule to null.

smart

The "smart" option enforces the use of === and !== except for these cases:

• Comparing two literal values
• Evaluating the value of typeof
• Comparing against null

Examples of incorrect code for the "smart" option:

/*eslint eqeqeq: ["error", "smart"]*/

// comparing two variables requires ===
a == b

// only one side is a literal
foo == true
bananas != 1

// comparing to undefined requires ===
value == undefined

Examples of correct code for the "smart" option:

/*eslint eqeqeq: ["error", "smart"]*/

typeof foo == 'undefined'
'hello' != 'world'
0 == 0
true == true
foo == null

allow-null

Deprecated: Instead of using this option use "always" and pass a "null" option property with value "ignore". This will tell ESLint to always enforce strict equality except when comparing with the null literal.

["error", "always", {"null": "ignore"}]

When Not To Use It

If you don't want to enforce a style for using equality operators, then it's safe to disable this rule. Source: http://eslint.org/docs/rules/

Require === and !== (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:

• [] == false
• [] == ![]
• 3 == "03"

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

Rule Details

This rule is aimed at eliminating the type-unsafe equality operators.

Examples of incorrect code for this rule:

/*eslint eqeqeq: "error"*/

if (x == 42) { }

if ("" == text) { }

if (obj.getStuff() != undefined) { }

The --fix option on the command line automatically fixes some problems reported by this rule. A problem is only fixed if one of the operands is a typeof expression, or if both operands are literals with the same type.

Options

always

The "always" option (default) enforces the use of === and !== in every situation (except when you opt-in to more specific handling of null [see below]).

Examples of incorrect code for the "always" option:

/*eslint eqeqeq: ["error", "always"]*/

a == b
foo == true
bananas != 1
value == undefined
typeof foo == 'undefined'
'hello' != 'world'
0 == 0
true == true
foo == null

Examples of correct code for the "always" option:

/*eslint eqeqeq: ["error", "always"]*/

a === b
foo === true
bananas !== 1
value === undefined
typeof foo === 'undefined'
'hello' !== 'world'
0 === 0
true === true
foo === null

This rule optionally takes a second argument, which should be an object with the following supported properties:

• "null": Customize how this rule treats null literals. Possible values:
  • always (default) - Always use === or !==.
  • never - Never use === or !== with null.
  • ignore - Do not apply this rule to null.

smart

The "smart" option enforces the use of === and !== except for these cases:

• Comparing two literal values
• Evaluating the value of typeof
• Comparing against null

Examples of incorrect code for the "smart" option:

/*eslint eqeqeq: ["error", "smart"]*/

// comparing two variables requires ===
a == b

// only one side is a literal
foo == true
bananas != 1

// comparing to undefined requires ===
value == undefined

Examples of correct code for the "smart" option:

/*eslint eqeqeq: ["error", "smart"]*/

typeof foo == 'undefined'
'hello' != 'world'
0 == 0
true == true
foo == null

allow-null

Deprecated: Instead of using this option use "always" and pass a "null" option property with value "ignore". This will tell ESLint to always enforce strict equality except when comparing with the null literal.

["error", "always", {"null": "ignore"}]

When Not To Use It

If you don't want to enforce a style for using equality operators, then it's safe to disable this rule. Source: http://eslint.org/docs/rules/

Require === and !== (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:

• [] == false
• [] == ![]
• 3 == "03"

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

Rule Details

This rule is aimed at eliminating the type-unsafe equality operators.

Examples of incorrect code for this rule:

/*eslint eqeqeq: "error"*/

if (x == 42) { }

if ("" == text) { }

if (obj.getStuff() != undefined) { }

The --fix option on the command line automatically fixes some problems reported by this rule. A problem is only fixed if one of the operands is a typeof expression, or if both operands are literals with the same type.

Options

always

The "always" option (default) enforces the use of === and !== in every situation (except when you opt-in to more specific handling of null [see below]).

Examples of incorrect code for the "always" option:

/*eslint eqeqeq: ["error", "always"]*/

a == b
foo == true
bananas != 1
value == undefined
typeof foo == 'undefined'
'hello' != 'world'
0 == 0
true == true
foo == null

Examples of correct code for the "always" option:

/*eslint eqeqeq: ["error", "always"]*/

a === b
foo === true
bananas !== 1
value === undefined
typeof foo === 'undefined'
'hello' !== 'world'
0 === 0
true === true
foo === null

This rule optionally takes a second argument, which should be an object with the following supported properties:

• "null": Customize how this rule treats null literals. Possible values:
  • always (default) - Always use === or !==.
  • never - Never use === or !== with null.
  • ignore - Do not apply this rule to null.

smart

The "smart" option enforces the use of === and !== except for these cases:

• Comparing two literal values
• Evaluating the value of typeof
• Comparing against null

Examples of incorrect code for the "smart" option:

/*eslint eqeqeq: ["error", "smart"]*/

// comparing two variables requires ===
a == b

// only one side is a literal
foo == true
bananas != 1

// comparing to undefined requires ===
value == undefined

Examples of correct code for the "smart" option:

/*eslint eqeqeq: ["error", "smart"]*/

typeof foo == 'undefined'
'hello' != 'world'
0 == 0
true == true
foo == null

allow-null

Deprecated: Instead of using this option use "always" and pass a "null" option property with value "ignore". This will tell ESLint to always enforce strict equality except when comparing with the null literal.

["error", "always", {"null": "ignore"}]

When Not To Use It

If you don't want to enforce a style for using equality operators, then it's safe to disable this rule. Source: http://eslint.org/docs/rules/

Require === and !== (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:

• [] == false
• [] == ![]
• 3 == "03"

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

Rule Details

This rule is aimed at eliminating the type-unsafe equality operators.

Examples of incorrect code for this rule:

/*eslint eqeqeq: "error"*/

if (x == 42) { }

if ("" == text) { }

if (obj.getStuff() != undefined) { }

The --fix option on the command line automatically fixes some problems reported by this rule. A problem is only fixed if one of the operands is a typeof expression, or if both operands are literals with the same type.

Options

always

The "always" option (default) enforces the use of === and !== in every situation (except when you opt-in to more specific handling of null [see below]).

Examples of incorrect code for the "always" option:

/*eslint eqeqeq: ["error", "always"]*/

a == b
foo == true
bananas != 1
value == undefined
typeof foo == 'undefined'
'hello' != 'world'
0 == 0
true == true
foo == null

Examples of correct code for the "always" option:

/*eslint eqeqeq: ["error", "always"]*/

a === b
foo === true
bananas !== 1
value === undefined
typeof foo === 'undefined'
'hello' !== 'world'
0 === 0
true === true
foo === null

This rule optionally takes a second argument, which should be an object with the following supported properties:

• "null": Customize how this rule treats null literals. Possible values:
  • always (default) - Always use === or !==.
  • never - Never use === or !== with null.
  • ignore - Do not apply this rule to null.

smart

The "smart" option enforces the use of === and !== except for these cases:

• Comparing two literal values
• Evaluating the value of typeof
• Comparing against null

Examples of incorrect code for the "smart" option:

/*eslint eqeqeq: ["error", "smart"]*/

// comparing two variables requires ===
a == b

// only one side is a literal
foo == true
bananas != 1

// comparing to undefined requires ===
value == undefined

Examples of correct code for the "smart" option:

/*eslint eqeqeq: ["error", "smart"]*/

typeof foo == 'undefined'
'hello' != 'world'
0 == 0
true == true
foo == null

allow-null

Deprecated: Instead of using this option use "always" and pass a "null" option property with value "ignore". This will tell ESLint to always enforce strict equality except when comparing with the null literal.

["error", "always", {"null": "ignore"}]

When Not To Use It

If you don't want to enforce a style for using equality operators, then it's safe to disable this rule. Source: http://eslint.org/docs/rules/

Duplicated Code

Duplicated code can lead to software that is hard to understand and difficult to change. The Don't Repeat Yourself (DRY) principle states:

Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.

When you violate DRY, bugs and maintenance problems are sure to follow. Duplicated code has a tendency to both continue to replicate and also to diverge (leaving bugs as two similar implementations differ in subtle ways).

Tuning

This issue has a mass of 68.

We set useful threshold defaults for the languages we support but you may want to adjust these settings based on your project guidelines.

The threshold configuration represents the minimum mass a code block must have to be analyzed for duplication. The lower the threshold, the more fine-grained the comparison.

If the engine is too easily reporting duplication, try raising the threshold. If you suspect that the engine isn't catching enough duplication, try lowering the threshold. The best setting tends to differ from language to language.

See codeclimate-duplication's documentation for more information about tuning the mass threshold in your .codeclimate.yml.

Refactorings

• Extract Method
• Extract Class
• Form Template Method
• Introduce Null Object
• Pull Up Method
• Pull Up Field
• Substitute Algorithm

Further Reading

• Don't Repeat Yourself on the C2 Wiki
• Duplicated Code on SourceMaking
• Refactoring: Improving the Design of Existing Code by Martin Fowler. Duplicated Code, p76

Duplicated Code

Duplicated code can lead to software that is hard to understand and difficult to change. The Don't Repeat Yourself (DRY) principle states:

Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.

When you violate DRY, bugs and maintenance problems are sure to follow. Duplicated code has a tendency to both continue to replicate and also to diverge (leaving bugs as two similar implementations differ in subtle ways).

Tuning

This issue has a mass of 54.

We set useful threshold defaults for the languages we support but you may want to adjust these settings based on your project guidelines.

The threshold configuration represents the minimum mass a code block must have to be analyzed for duplication. The lower the threshold, the more fine-grained the comparison.

If the engine is too easily reporting duplication, try raising the threshold. If you suspect that the engine isn't catching enough duplication, try lowering the threshold. The best setting tends to differ from language to language.

See codeclimate-duplication's documentation for more information about tuning the mass threshold in your .codeclimate.yml.

Refactorings

• Extract Method
• Extract Class
• Form Template Method
• Introduce Null Object
• Pull Up Method
• Pull Up Field
• Substitute Algorithm

Further Reading

• Don't Repeat Yourself on the C2 Wiki
• Duplicated Code on SourceMaking
• Refactoring: Improving the Design of Existing Code by Martin Fowler. Duplicated Code, p76

For more information visit Source: http://eslint.org/docs/rules/