Close

Disallow trailing spaces at the end of lines (no-trailing-spaces)

(fixable) The --fix option on the [command line](../user-guide/command-line-interface#fix) automatically fixes problems reported by this rule.

Sometimes in the course of editing files, you can end up with extra whitespace at the end of lines. These whitespace differences can be picked up by source control systems and flagged as diffs, causing frustration for developers. While this extra whitespace causes no functional issues, many code conventions require that trailing spaces be removed before checkin.

Rule Details

The following patterns are considered problems:

/*eslint no-trailing-spaces: "error"*/

// spaces, tabs and unicode whitespaces
// are not allowed at the end of lines
var foo = 0;//•••••
var baz = 5;//••

The following patterns are not considered problems:

/*eslint no-trailing-spaces: "error"*/

var foo = 0;

var baz = 5;

Options

There is one option for this rule, skipBlankLines. When set to true, the rule will not flag any lines that are made up purely of whitespace. In short, if a line is zero-length after being trimmed of whitespace, then the rule will not flag that line when skipBlankLines is enabled.

You can enable this option in your config like this:

{
    "no-trailing-spaces": ["error", { "skipBlankLines": true }]
}

With this option enabled, The following patterns are not considered problems:

/*eslint no-trailing-spaces: ["error", { "skipBlankLines": true }]*/

var foo = 0;
//••••
var baz = 5;

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

    function mutatedGenesData(_selectedGenesMap, _selectedSampleUids) {

Close

Require JSDoc comment (require-jsdoc)

JSDoc is a JavaScript API documentation generator. It uses specially-formatted comments inside of code to generate API documentation automatically. For example, this is what a JSDoc comment looks like for a function:

/**
 * Adds two numbers together.
 * @param {int} num1 The first number.
 * @param {int} num2 The second number.
 * @returns {int} The sum of the two numbers.
 */
function sum(num1, num2) {
    return num1 + num2;
}

Some style guides require JSDoc comments for all functions as a way of explaining function behavior.

Rule Details

This rule generates warnings for nodes that do not have JSDoc comments when they should. Supported nodes:

• FunctionDeclaration
• ClassDeclaration
• MethodDefinition

Options

This rule accepts a require object with its properties as

• FunctionDeclaration (default: true)
• ClassDeclaration (default: false)
• MethodDefinition (default: false)

Default option settings are

{
    "require-jsdoc": ["error", {
        "require": {
            "FunctionDeclaration": true,
            "MethodDefinition": false,
            "ClassDeclaration": false
        }
    }]
}

The following patterns are considered problems:

/*eslint "require-jsdoc": ["error", {
    "require": {
        "FunctionDeclaration": true,
        "MethodDefinition": true,
        "ClassDeclaration": true
    }
}]*/

function foo() {
    return 10;
}

class Test{
    getDate(){}
}

The following patterns are not considered problems:

/*eslint "require-jsdoc": ["error", {
    "require": {
        "FunctionDeclaration": true,
        "MethodDefinition": true,
        "ClassDeclaration": true
    }
}]*/

/**
* It returns 10
*/
function foo() {
    return 10;
}

/**
* It returns 10
*/
var foo = function() {
    return 10;
}

var array = [1,2,3];
array.filter(function(item) {
    return item > 2;
});

/**
* It returns 10
*/
class Test{
    /**
    * returns the date
    */
    getDate(){}
}

When Not To Use It

If you do not require JSDoc for your functions, then you can leave this rule off.

Related Rules

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

            if (typeof genePanelMap[item.gene] !== 'undefined') {

Close

Disallow use of negated expressions in conditions (no-negated-condition)

Checks against the use of a negated expression in an if condition when the else branch is not empty or in a ternary operator. Negated conditions are more difficult to understand. Code can be made more readable by inverting the condition instead.

For example:

if (!a) {
    doSomething();
}
else {
    doSomethingElse();
}

should instead be written as:

if (a) {
    doSomethingElse();
}
else {
    doSomething();
}

Rule Details

The rule is aimed at preventing the use of a negated expression in a condition.

The following patterns are considered warnings:

/*eslint no-negated-condition: "error"*/

if (!a) {
    doSomething();
} else {
    doSomethingElse();
}

if (a != b) {
    doSomething();
} else {
    doSomethingElse();
}

if (a !== b) {
    doSomething();
} else {
    doSomethingElse();
}


!a ? b : c

The following patterns are not warnings:

/*eslint no-negated-condition: "error"*/

if (!a) {
    doSomething();
}

if (!a) {
    doSomething();
} else if (b) {
    doSomething();
}

if (a != b) {
    doSomething();
}

a ? b : c

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

    function reactSubmitClickCallback() {

Close

Require JSDoc comment (require-jsdoc)

JSDoc is a JavaScript API documentation generator. It uses specially-formatted comments inside of code to generate API documentation automatically. For example, this is what a JSDoc comment looks like for a function:

/**
 * Adds two numbers together.
 * @param {int} num1 The first number.
 * @param {int} num2 The second number.
 * @returns {int} The sum of the two numbers.
 */
function sum(num1, num2) {
    return num1 + num2;
}

Some style guides require JSDoc comments for all functions as a way of explaining function behavior.

Rule Details

This rule generates warnings for nodes that do not have JSDoc comments when they should. Supported nodes:

• FunctionDeclaration
• ClassDeclaration
• MethodDefinition

Options

This rule accepts a require object with its properties as

• FunctionDeclaration (default: true)
• ClassDeclaration (default: false)
• MethodDefinition (default: false)

Default option settings are

{
    "require-jsdoc": ["error", {
        "require": {
            "FunctionDeclaration": true,
            "MethodDefinition": false,
            "ClassDeclaration": false
        }
    }]
}

The following patterns are considered problems:

/*eslint "require-jsdoc": ["error", {
    "require": {
        "FunctionDeclaration": true,
        "MethodDefinition": true,
        "ClassDeclaration": true
    }
}]*/

function foo() {
    return 10;
}

class Test{
    getDate(){}
}

The following patterns are not considered problems:

/*eslint "require-jsdoc": ["error", {
    "require": {
        "FunctionDeclaration": true,
        "MethodDefinition": true,
        "ClassDeclaration": true
    }
}]*/

/**
* It returns 10
*/
function foo() {
    return 10;
}

/**
* It returns 10
*/
var foo = function() {
    return 10;
}

var array = [1,2,3];
array.filter(function(item) {
    return item > 2;
});

/**
* It returns 10
*/
class Test{
    /**
    * returns the date
    */
    getDate(){}
}

When Not To Use It

If you do not require JSDoc for your functions, then you can leave this rule off.

Related Rules

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

    events: {

Close

Quoting Style for Property Names (quote-props)

Object literal property names can be defined in two ways: using literals or using strings. For example, these two objects are equivalent:

var object1 = {
    property: true
};

var object2 = {
    "property": true
};

In many cases, it doesn't matter if you choose to use an identifier instead of a string or vice-versa. Even so, you might decide to enforce a consistent style in your code.

There are, however, some occasions when you must use quotes:

1. If you are using an ECMAScript 3 JavaScript engine (such as IE8) and you want to use a keyword (such as if) as a property name. This restriction was removed in ECMAScript 5.
2. You want to use a non-identifier character in your property name, such as having a property with a space like "one two".

Another example where quotes do matter is when using numeric literals as property keys:

var object = {
    1e2: 1,
    100: 2
};

This may look alright at first sight, but this code in fact throws a syntax error in ECMAScript 5 strict mode. This happens because 1e2 and 100 are coerced into strings before getting used as the property name. Both String(1e2) and String(100) happen to be equal to "100", which causes the "Duplicate data property in object literal not allowed in strict mode" error. Issues like that can be tricky to debug, so some prefer to require quotes around all property names.

Rule Details

This rule aims to enforce use of quotes in property names and as such will flag any properties that don't use quotes (default behavior).

Options

There are four behaviors for this rule: "always" (default), "as-needed", "consistent" and "consistent-as-needed". You can define these options in your configuration as:

{
    "quote-props": ["error", "as-needed"]
}

"always"

When configured with "always" as the first option (the default), quoting for all properties will be enforced. Some believe that ensuring property names in object literals are always wrapped in quotes is generally a good idea, since depending on the property name you may need to quote them anyway. Consider this example:

var object = {
    foo: "bar",
    baz: 42,
    "qux-lorem": true
};

Here, the properties foo and baz are not wrapped in quotes, but qux-lorem is, because it doesn’t work without the quotes. This is rather inconsistent. Instead, you may prefer to quote names of all properties:

var object = {
    "foo": "bar",
    "baz": 42,
    "qux-lorem": true
};

or, if you prefer single quotes:

var object = {
    'foo': 'bar',
    'baz': 42,
    'qux-lorem': true
};

When configured with "always" as the first option (the default), quoting for all properties will be enforced. The following patterns are considered problems:

/*eslint quote-props: ["error", "always"]*/

var object = {
    foo: "bar",
    baz: 42,
    "qux-lorem": true
};

The following patterns are not considered problems:

/*eslint quote-props: ["error", "always"]*/
/*eslint-env es6*/

var object1 = {
    "foo": "bar",
    "baz": 42,
    "qux-lorem": true
};

var object2 = {
    'foo': 'bar',
    'baz': 42,
    'qux-lorem': true
};

var object3 = {
    foo() {
        return;
    }
};

"as-needed"

When configured with "as-needed" as the first option, quotes will be enforced when they are strictly required, and unnecessary quotes will cause warnings. The following patterns are considered problems:

/*eslint quote-props: ["error", "as-needed"]*/

var object = {
    "a": 0,
    "0": 0,
    "true": 0,
    "null": 0
};

The following patterns are not considered problems:

/*eslint quote-props: ["error", "as-needed"]*/
/*eslint-env es6*/

var object1 = {
    "a-b": 0,
    "0x0": 0,
    "1e2": 0
};

var object2 = {
    foo: 'bar',
    baz: 42,
    true: 0,
    0: 0,
    'qux-lorem': true
};

var object3 = {
    foo() {
        return;
    }
};

When the "as-needed" mode is selected, an additional keywords option can be provided. This flag indicates whether language keywords should be quoted as properties. By default it is set to false.

{
    "quote-props": ["error", "as-needed", { "keywords": true }]
}

When keywords is set to true, the following patterns become problems:

/*eslint quote-props: ["error", "as-needed", { "keywords": true }]*/

var x = {
    while: 1,
    volatile: "foo"
};

Another modifier for this rule is the unnecessary option which defaults to true. Setting this to false will prevent the rule from complaining about unnecessarily quoted properties. This comes in handy when you only care about quoting keywords.

{
    "quote-props": ["error", "as-needed", { "keywords": true, "unnecessary": false }]
}

When unnecessary is set to false, the following patterns stop being problems:

/*eslint quote-props: ["error", "as-needed", { "keywords": true, "unnecessary": false }]*/

var x = {
    "while": 1,
    "foo": "bar"  // Would normally have caused a warning
};

A numbers flag, with default value false, can also be used as a modifier for the "as-needed" mode. When it is set to true, numeric literals should always be quoted.

{
    "quote-props": ["error", "as-needed", {"numbers": true}]
}

When numbers is set to true, the following patterns become problems:

/*eslint quote-props: ["error", "as-needed", { "numbers": true }]*/

var x = {
    100: 1
}

and the following patterns stop being problems:

var x = {
    "100": 1
}

"consistent"

When configured with "consistent", the patterns below are considered problems. Basically "consistent" means all or no properties are expected to be quoted, in other words quoting style can't be mixed within an object. Please note the latter situation (no quotation at all) isn't always possible as some property names require quoting.

/*eslint quote-props: ["error", "consistent"]*/

var object1 = {
    foo: "bar",
    "baz": 42,
    "qux-lorem": true
};

var object2 = {
    'foo': 'bar',
    baz: 42
};

The following patterns are not considered problems:

/*eslint quote-props: ["error", "consistent"]*/

var object1 = {
    "foo": "bar",
    "baz": 42,
    "qux-lorem": true
};

var object2 = {
    'foo': 'bar',
    'baz': 42
};

var object3 = {
    foo: 'bar',
    baz: 42
};

"consistent-as-needed"

When configured with "consistent-as-needed", the behavior is similar to "consistent" with one difference. Namely, properties' quoting should be consistent (as in "consistent") but whenever all quotes are redundant a warning is raised. In other words if at least one property name has to be quoted (like qux-lorem) then all property names must be quoted, otherwise no properties can be quoted. The following patterns are considered problems:

/*eslint quote-props: ["error", "consistent-as-needed"]*/

var object1 = {
    foo: "bar",
    "baz": 42,
    "qux-lorem": true
};

var object2 = {
    'foo': 'bar',
    'baz': 42
};

The following patterns are not considered problems:

/*eslint quote-props: ["error", "consistent-as-needed"]*/

var object1 = {
    "foo": "bar",
    "baz": 42,
    "qux-lorem": true
};

var object2 = {
    foo: 'bar',
    baz: 42
};

When the "consistent-as-needed" mode is selected, an additional keywords option can be provided. This flag indicates whether language keywords can be used unquoted as properties. By default it is set to false.

{
    "quote-props": ["error", "consistent-as-needed", { "keywords": true }]
}

When keywords is set to true, the following patterns are considered problems:

/*eslint quote-props: ["error", "consistent-as-needed", { "keywords": true }]*/

var x = {
    while: 1,
    volatile: "foo"
};

When Not To Use It

If you don't care if property names are consistently wrapped in quotes or not, and you don't target legacy ES3 environments, turn this rule off.

Further Reading

• Reserved words as property names
• Unquoted property names / object keys in JavaScript Source: http://eslint.org/docs/rules/

    function initCanvasDownloadData() {

Close

Require JSDoc comment (require-jsdoc)

JSDoc is a JavaScript API documentation generator. It uses specially-formatted comments inside of code to generate API documentation automatically. For example, this is what a JSDoc comment looks like for a function:

/**
 * Adds two numbers together.
 * @param {int} num1 The first number.
 * @param {int} num2 The second number.
 * @returns {int} The sum of the two numbers.
 */
function sum(num1, num2) {
    return num1 + num2;
}

Some style guides require JSDoc comments for all functions as a way of explaining function behavior.

Rule Details

This rule generates warnings for nodes that do not have JSDoc comments when they should. Supported nodes:

• FunctionDeclaration
• ClassDeclaration
• MethodDefinition

Options

This rule accepts a require object with its properties as

• FunctionDeclaration (default: true)
• ClassDeclaration (default: false)
• MethodDefinition (default: false)

Default option settings are

{
    "require-jsdoc": ["error", {
        "require": {
            "FunctionDeclaration": true,
            "MethodDefinition": false,
            "ClassDeclaration": false
        }
    }]
}

The following patterns are considered problems:

/*eslint "require-jsdoc": ["error", {
    "require": {
        "FunctionDeclaration": true,
        "MethodDefinition": true,
        "ClassDeclaration": true
    }
}]*/

function foo() {
    return 10;
}

class Test{
    getDate(){}
}

The following patterns are not considered problems:

/*eslint "require-jsdoc": ["error", {
    "require": {
        "FunctionDeclaration": true,
        "MethodDefinition": true,
        "ClassDeclaration": true
    }
}]*/

/**
* It returns 10
*/
function foo() {
    return 10;
}

/**
* It returns 10
*/
var foo = function() {
    return 10;
}

var array = [1,2,3];
array.filter(function(item) {
    return item > 2;
});

/**
* It returns 10
*/
class Test{
    /**
    * returns the date
    */
    getDate(){}
}

When Not To Use It

If you do not require JSDoc for your functions, then you can leave this rule off.

Related Rules

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

    function pieLabelMouseEnter(data) {

Close

Require JSDoc comment (require-jsdoc)

JSDoc is a JavaScript API documentation generator. It uses specially-formatted comments inside of code to generate API documentation automatically. For example, this is what a JSDoc comment looks like for a function:

/**
 * Adds two numbers together.
 * @param {int} num1 The first number.
 * @param {int} num2 The second number.
 * @returns {int} The sum of the two numbers.
 */
function sum(num1, num2) {
    return num1 + num2;
}

Some style guides require JSDoc comments for all functions as a way of explaining function behavior.

Rule Details

This rule generates warnings for nodes that do not have JSDoc comments when they should. Supported nodes:

• FunctionDeclaration
• ClassDeclaration
• MethodDefinition

Options

This rule accepts a require object with its properties as

• FunctionDeclaration (default: true)
• ClassDeclaration (default: false)
• MethodDefinition (default: false)

Default option settings are

{
    "require-jsdoc": ["error", {
        "require": {
            "FunctionDeclaration": true,
            "MethodDefinition": false,
            "ClassDeclaration": false
        }
    }]
}

The following patterns are considered problems:

/*eslint "require-jsdoc": ["error", {
    "require": {
        "FunctionDeclaration": true,
        "MethodDefinition": true,
        "ClassDeclaration": true
    }
}]*/

function foo() {
    return 10;
}

class Test{
    getDate(){}
}

The following patterns are not considered problems:

/*eslint "require-jsdoc": ["error", {
    "require": {
        "FunctionDeclaration": true,
        "MethodDefinition": true,
        "ClassDeclaration": true
    }
}]*/

/**
* It returns 10
*/
function foo() {
    return 10;
}

/**
* It returns 10
*/
var foo = function() {
    return 10;
}

var array = [1,2,3];
array.filter(function(item) {
    return item > 2;
});

/**
* It returns 10
*/
class Test{
    /**
    * returns the date
    */
    getDate(){}
}

When Not To Use It

If you do not require JSDoc for your functions, then you can leave this rule off.

Related Rules

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

      v.renderedReactTable = ReactDOM.render(testElement, document.getElementById(targetId));

Close

enforce a maximum line length (max-len)

Very long lines of code in any language can be difficult to read. In order to aid in readability and maintainability many coders have developed a convention to limit lines of code to X number of characters (traditionally 80 characters).

var foo = { "bar": "This is a bar.", "baz": { "qux": "This is a qux" }, "difficult": "to read" }; // very long

Rule Details

This rule enforces a maximum line length to increase code readability and maintainability.

Note: This rule calculates the length of a line via code points, not characters. That means if you use a double-byte character in your code, it will count as 2 code points instead of 1, and 2 will be used to calculate line length. This is a technical limitation of JavaScript that is made easier with ES2015, and we will look to update this when ES2015 is available in Node.js.

Options

This rule has a number or object option:

• "code" (default 80) enforces a maximum line length
• "tabWidth" (default 4) specifies the character width for tab characters
• "comments" enforces a maximum line length for comments; defaults to value of code
• "ignorePattern" ignores lines matching a regular expression; can only match a single line and need to be double escaped when written in YAML or JSON
• "ignoreComments": true ignores all trailing comments and comments on their own line
• "ignoreTrailingComments": true ignores only trailing comments
• "ignoreUrls": true ignores lines that contain a URL

code

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

/*eslint max-len: ["error", 80]*/

var foo = { "bar": "This is a bar.", "baz": { "qux": "This is a qux" }, "difficult": "to read" };

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

/*eslint max-len: ["error", 80]*/

var foo = {
  "bar": "This is a bar.",
  "baz": { "qux": "This is a qux" },
  "easier": "to read"
};

tabWidth

Examples of incorrect code for this rule with the default { "tabWidth": 4 } option:

/*eslint max-len: ["error", 80, 4]*/

\t  \t  var foo = { "bar": "This is a bar.", "baz": { "qux": "This is a qux" } };

Examples of correct code for this rule with the default { "tabWidth": 4 } option:

/*eslint max-len: ["error", 80, 4]*/

\t  \t  var foo = {
\t  \t  \t  \t  "bar": "This is a bar.",
\t  \t  \t  \t  "baz": { "qux": "This is a qux" }
\t  \t  };

comments

Examples of incorrect code for this rule with the { "comments": 65 } option:

/*eslint max-len: ["error", { "comments": 65 }]*/

/**
 * This is a comment that violates the maximum line length we have specified
**/

ignoreComments

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

/*eslint max-len: ["error", { "ignoreComments": true }]*/

/**
 * This is a really really really really really really really really really long comment
**/

ignoreTrailingComments

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

/*eslint max-len: ["error", { "ignoreTrailingComments": true }]*/

var foo = 'bar'; // This is a really really really really really really really long comment

ignoreUrls

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

/*eslint max-len: ["error", { "ignoreUrls": true }]*/

var url = 'https://www.example.com/really/really/really/really/really/really/really/long';

ignorePattern

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

/*eslint max-len: ["error", { "ignorePattern": "^\\s*var\\s.+=\\s*require\\s*\\(/" }]*/

var dep = require('really/really/really/really/really/really/really/really/long/module');

Related Rules

• [complexity](complexity.md)
• [max-depth](max-depth.md)
• [max-nested-callbacks](max-nested-callbacks.md)
• [max-params](max-params.md)
• [max-statements](max-statements.md) Source: http://eslint.org/docs/rules/

        return !isNaN(datum.FRACTION_GENOME_ALTERED) && !isNaN(datum.MUTATION_COUNT);

Close

enforce a maximum line length (max-len)

Very long lines of code in any language can be difficult to read. In order to aid in readability and maintainability many coders have developed a convention to limit lines of code to X number of characters (traditionally 80 characters).

var foo = { "bar": "This is a bar.", "baz": { "qux": "This is a qux" }, "difficult": "to read" }; // very long

Rule Details

This rule enforces a maximum line length to increase code readability and maintainability.

Note: This rule calculates the length of a line via code points, not characters. That means if you use a double-byte character in your code, it will count as 2 code points instead of 1, and 2 will be used to calculate line length. This is a technical limitation of JavaScript that is made easier with ES2015, and we will look to update this when ES2015 is available in Node.js.

Options

This rule has a number or object option:

• "code" (default 80) enforces a maximum line length
• "tabWidth" (default 4) specifies the character width for tab characters
• "comments" enforces a maximum line length for comments; defaults to value of code
• "ignorePattern" ignores lines matching a regular expression; can only match a single line and need to be double escaped when written in YAML or JSON
• "ignoreComments": true ignores all trailing comments and comments on their own line
• "ignoreTrailingComments": true ignores only trailing comments
• "ignoreUrls": true ignores lines that contain a URL

code

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

/*eslint max-len: ["error", 80]*/

var foo = { "bar": "This is a bar.", "baz": { "qux": "This is a qux" }, "difficult": "to read" };

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

/*eslint max-len: ["error", 80]*/

var foo = {
  "bar": "This is a bar.",
  "baz": { "qux": "This is a qux" },
  "easier": "to read"
};

tabWidth

Examples of incorrect code for this rule with the default { "tabWidth": 4 } option:

/*eslint max-len: ["error", 80, 4]*/

\t  \t  var foo = { "bar": "This is a bar.", "baz": { "qux": "This is a qux" } };

Examples of correct code for this rule with the default { "tabWidth": 4 } option:

/*eslint max-len: ["error", 80, 4]*/

\t  \t  var foo = {
\t  \t  \t  \t  "bar": "This is a bar.",
\t  \t  \t  \t  "baz": { "qux": "This is a qux" }
\t  \t  };

comments

Examples of incorrect code for this rule with the { "comments": 65 } option:

/*eslint max-len: ["error", { "comments": 65 }]*/

/**
 * This is a comment that violates the maximum line length we have specified
**/

ignoreComments

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

/*eslint max-len: ["error", { "ignoreComments": true }]*/

/**
 * This is a really really really really really really really really really long comment
**/

ignoreTrailingComments

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

/*eslint max-len: ["error", { "ignoreTrailingComments": true }]*/

var foo = 'bar'; // This is a really really really really really really really long comment

ignoreUrls

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

/*eslint max-len: ["error", { "ignoreUrls": true }]*/

var url = 'https://www.example.com/really/really/really/really/really/really/really/long';

ignorePattern

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

/*eslint max-len: ["error", { "ignorePattern": "^\\s*var\\s.+=\\s*require\\s*\\(/" }]*/

var dep = require('really/really/really/really/really/really/really/really/long/module');

Related Rules

• [complexity](complexity.md)
• [max-depth](max-depth.md)
• [max-nested-callbacks](max-nested-callbacks.md)
• [max-params](max-params.md)
• [max-statements](max-statements.md) Source: http://eslint.org/docs/rules/

        } else {

Close

Disallow return before else (no-else-return)

If an if block contains a return statement, the else block becomes unnecessary. Its contents can be placed outside of the block.

function foo() {
    if (x) {
        return y;
    } else {
        return z;
    }
}

Rule Details

This rule is aimed at highlighting an unnecessary block of code following an if containing a return statement. As such, it will warn when it encounters an else following a chain of ifs, all of them containing a return statement.

Examples of incorrect code for this rule:

/*eslint no-else-return: "error"*/

function foo() {
    if (x) {
        return y;
    } else {
        return z;
    }
}

function foo() {
    if (x) {
        return y;
    } else if (z) {
        return w;
    } else {
        return t;
    }
}

function foo() {
    if (x) {
        return y;
    } else {
        var t = "foo";
    }

    return t;
}

// Two warnings for nested occurrences
function foo() {
    if (x) {
        if (y) {
            return y;
        } else {
            return x;
        }
    } else {
        return z;
    }
}

Examples of correct code for this rule:

/*eslint no-else-return: "error"*/

function foo() {
    if (x) {
        return y;
    }

    return z;
}

function foo() {
    if (x) {
        return y;
    } else if (z) {
        var t = "foo";
    } else {
        return w;
    }
}

function foo() {
    if (x) {
        if (z) {
            return y;
        }
    } else {
        return z;
    }
}

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

            'Exclude patients with NA for any of the selected attribute(s)</span></div>');

Close

enforce a maximum line length (max-len)

Very long lines of code in any language can be difficult to read. In order to aid in readability and maintainability many coders have developed a convention to limit lines of code to X number of characters (traditionally 80 characters).

var foo = { "bar": "This is a bar.", "baz": { "qux": "This is a qux" }, "difficult": "to read" }; // very long

Rule Details

This rule enforces a maximum line length to increase code readability and maintainability.

Note: This rule calculates the length of a line via code points, not characters. That means if you use a double-byte character in your code, it will count as 2 code points instead of 1, and 2 will be used to calculate line length. This is a technical limitation of JavaScript that is made easier with ES2015, and we will look to update this when ES2015 is available in Node.js.

Options

This rule has a number or object option:

• "code" (default 80) enforces a maximum line length
• "tabWidth" (default 4) specifies the character width for tab characters
• "comments" enforces a maximum line length for comments; defaults to value of code
• "ignorePattern" ignores lines matching a regular expression; can only match a single line and need to be double escaped when written in YAML or JSON
• "ignoreComments": true ignores all trailing comments and comments on their own line
• "ignoreTrailingComments": true ignores only trailing comments
• "ignoreUrls": true ignores lines that contain a URL

code

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

/*eslint max-len: ["error", 80]*/

var foo = { "bar": "This is a bar.", "baz": { "qux": "This is a qux" }, "difficult": "to read" };

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

/*eslint max-len: ["error", 80]*/

var foo = {
  "bar": "This is a bar.",
  "baz": { "qux": "This is a qux" },
  "easier": "to read"
};

tabWidth

Examples of incorrect code for this rule with the default { "tabWidth": 4 } option:

/*eslint max-len: ["error", 80, 4]*/

\t  \t  var foo = { "bar": "This is a bar.", "baz": { "qux": "This is a qux" } };

Examples of correct code for this rule with the default { "tabWidth": 4 } option:

/*eslint max-len: ["error", 80, 4]*/

\t  \t  var foo = {
\t  \t  \t  \t  "bar": "This is a bar.",
\t  \t  \t  \t  "baz": { "qux": "This is a qux" }
\t  \t  };

comments

Examples of incorrect code for this rule with the { "comments": 65 } option:

/*eslint max-len: ["error", { "comments": 65 }]*/

/**
 * This is a comment that violates the maximum line length we have specified
**/

ignoreComments

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

/*eslint max-len: ["error", { "ignoreComments": true }]*/

/**
 * This is a really really really really really really really really really long comment
**/

ignoreTrailingComments

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

/*eslint max-len: ["error", { "ignoreTrailingComments": true }]*/

var foo = 'bar'; // This is a really really really really really really really long comment

ignoreUrls

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

/*eslint max-len: ["error", { "ignoreUrls": true }]*/

var url = 'https://www.example.com/really/really/really/really/really/really/really/long';

ignorePattern

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

/*eslint max-len: ["error", { "ignorePattern": "^\\s*var\\s.+=\\s*require\\s*\\(/" }]*/

var dep = require('really/really/really/really/really/really/really/really/long/module');

Related Rules

• [complexity](complexity.md)
• [max-depth](max-depth.md)
• [max-nested-callbacks](max-nested-callbacks.md)
• [max-params](max-params.md)
• [max-statements](max-statements.md) Source: http://eslint.org/docs/rules/

          .html(message)

Close

Enforce or Disallow Semicolons (semi)

(fixable) The --fix option on the [command line](../user-guide/command-line-interface#fix) automatically fixes problems reported by this rule.

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 says that since semicolons are inserted automatically, they are optional and do not need to be inserted manually. However, the ASI mechanism can also be tricky to people who don't use semicolons. 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 is aimed at ensuring consistent use of semicolons. You can decide whether or not to require semicolons at the end of statements.

Options

The rule takes one or two options. The first one is a string, which could be "always" or "never". The default is "always". The second one is an object for more fine-grained configuration when the first option is "always".

You can set the option in configuration like this:

"always"

By using the default option, semicolons must be used any place where they are valid.

semi: ["error", "always"]

The following patterns are considered problems:

/*eslint semi: "error"*/

var name = "ESLint"

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

The following patterns are not considered problems:

/*eslint semi: "error"*/

var name = "ESLint";

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

Fine-grained control

When setting the first option as "always", an additional option can be added to omit the last semicolon in a one-line block, that is, a block in which its braces (and therefore the content of the block) are in the same line:

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

The following patterns are considered problems:

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

if (foo) {
    bar()
}

if (foo) { bar(); }

The following patterns are not considered problems:

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

if (foo) { bar() }

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

"never"

If you want to enforce that semicolons are never used, switch the configuration to:

semi: [2, "never"]

Then, the following patterns are considered problems:

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

var name = "ESLint";

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

And the following patterns are not considered problems:

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

var name = "ESLint"

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

Even in "never" mode, semicolons are still allowed to disambiguate statements beginning with [, (, /, +, or -:

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

var name = "ESLint"

;(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
• Understanding Automatic Semicolon Insertion in JavaScript

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/

          .html(message)

Close

Enforce or Disallow Semicolons (semi)

(fixable) The --fix option on the [command line](../user-guide/command-line-interface#fix) automatically fixes problems reported by this rule.

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 says that since semicolons are inserted automatically, they are optional and do not need to be inserted manually. However, the ASI mechanism can also be tricky to people who don't use semicolons. 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 is aimed at ensuring consistent use of semicolons. You can decide whether or not to require semicolons at the end of statements.

Options

The rule takes one or two options. The first one is a string, which could be "always" or "never". The default is "always". The second one is an object for more fine-grained configuration when the first option is "always".

You can set the option in configuration like this:

"always"

By using the default option, semicolons must be used any place where they are valid.

semi: ["error", "always"]

The following patterns are considered problems:

/*eslint semi: "error"*/

var name = "ESLint"

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

The following patterns are not considered problems:

/*eslint semi: "error"*/

var name = "ESLint";

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

Fine-grained control

When setting the first option as "always", an additional option can be added to omit the last semicolon in a one-line block, that is, a block in which its braces (and therefore the content of the block) are in the same line:

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

The following patterns are considered problems:

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

if (foo) {
    bar()
}

if (foo) { bar(); }

The following patterns are not considered problems:

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

if (foo) { bar() }

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

"never"

If you want to enforce that semicolons are never used, switch the configuration to:

semi: [2, "never"]

Then, the following patterns are considered problems:

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

var name = "ESLint";

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

And the following patterns are not considered problems:

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

var name = "ESLint"

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

Even in "never" mode, semicolons are still allowed to disambiguate statements beginning with [, (, /, +, or -:

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

var name = "ESLint"

;(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
• Understanding Automatic Semicolon Insertion in JavaScript

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/

                              window.cbioURL + 'study?id=' + self_.savedVC.id + '</a>');

Close

enforce a maximum line length (max-len)

Very long lines of code in any language can be difficult to read. In order to aid in readability and maintainability many coders have developed a convention to limit lines of code to X number of characters (traditionally 80 characters).

var foo = { "bar": "This is a bar.", "baz": { "qux": "This is a qux" }, "difficult": "to read" }; // very long

Rule Details

This rule enforces a maximum line length to increase code readability and maintainability.

Note: This rule calculates the length of a line via code points, not characters. That means if you use a double-byte character in your code, it will count as 2 code points instead of 1, and 2 will be used to calculate line length. This is a technical limitation of JavaScript that is made easier with ES2015, and we will look to update this when ES2015 is available in Node.js.

Options

This rule has a number or object option:

• "code" (default 80) enforces a maximum line length
• "tabWidth" (default 4) specifies the character width for tab characters
• "comments" enforces a maximum line length for comments; defaults to value of code
• "ignorePattern" ignores lines matching a regular expression; can only match a single line and need to be double escaped when written in YAML or JSON
• "ignoreComments": true ignores all trailing comments and comments on their own line
• "ignoreTrailingComments": true ignores only trailing comments
• "ignoreUrls": true ignores lines that contain a URL

code

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

/*eslint max-len: ["error", 80]*/

var foo = { "bar": "This is a bar.", "baz": { "qux": "This is a qux" }, "difficult": "to read" };

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

/*eslint max-len: ["error", 80]*/

var foo = {
  "bar": "This is a bar.",
  "baz": { "qux": "This is a qux" },
  "easier": "to read"
};

tabWidth

Examples of incorrect code for this rule with the default { "tabWidth": 4 } option:

/*eslint max-len: ["error", 80, 4]*/

\t  \t  var foo = { "bar": "This is a bar.", "baz": { "qux": "This is a qux" } };

Examples of correct code for this rule with the default { "tabWidth": 4 } option:

/*eslint max-len: ["error", 80, 4]*/

\t  \t  var foo = {
\t  \t  \t  \t  "bar": "This is a bar.",
\t  \t  \t  \t  "baz": { "qux": "This is a qux" }
\t  \t  };

comments

Examples of incorrect code for this rule with the { "comments": 65 } option:

/*eslint max-len: ["error", { "comments": 65 }]*/

/**
 * This is a comment that violates the maximum line length we have specified
**/

ignoreComments

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

/*eslint max-len: ["error", { "ignoreComments": true }]*/

/**
 * This is a really really really really really really really really really long comment
**/

ignoreTrailingComments

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

/*eslint max-len: ["error", { "ignoreTrailingComments": true }]*/

var foo = 'bar'; // This is a really really really really really really really long comment

ignoreUrls

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

/*eslint max-len: ["error", { "ignoreUrls": true }]*/

var url = 'https://www.example.com/really/really/really/really/really/really/really/long';

ignorePattern

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

/*eslint max-len: ["error", { "ignorePattern": "^\\s*var\\s.+=\\s*require\\s*\\(/" }]*/

var dep = require('really/really/really/really/really/really/really/really/long/module');

Related Rules

• [complexity](complexity.md)
• [max-depth](max-depth.md)
• [max-nested-callbacks](max-nested-callbacks.md)
• [max-params](max-params.md)
• [max-statements](max-statements.md) Source: http://eslint.org/docs/rules/

                              'please try again later.</span>')

Close

Enforce or Disallow Semicolons (semi)

(fixable) The --fix option on the [command line](../user-guide/command-line-interface#fix) automatically fixes problems reported by this rule.

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 says that since semicolons are inserted automatically, they are optional and do not need to be inserted manually. However, the ASI mechanism can also be tricky to people who don't use semicolons. 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 is aimed at ensuring consistent use of semicolons. You can decide whether or not to require semicolons at the end of statements.

Options

The rule takes one or two options. The first one is a string, which could be "always" or "never". The default is "always". The second one is an object for more fine-grained configuration when the first option is "always".

You can set the option in configuration like this:

"always"

By using the default option, semicolons must be used any place where they are valid.

semi: ["error", "always"]

The following patterns are considered problems:

/*eslint semi: "error"*/

var name = "ESLint"

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

The following patterns are not considered problems:

/*eslint semi: "error"*/

var name = "ESLint";

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

Fine-grained control

When setting the first option as "always", an additional option can be added to omit the last semicolon in a one-line block, that is, a block in which its braces (and therefore the content of the block) are in the same line:

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

The following patterns are considered problems:

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

if (foo) {
    bar()
}

if (foo) { bar(); }

The following patterns are not considered problems:

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

if (foo) { bar() }

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

"never"

If you want to enforce that semicolons are never used, switch the configuration to:

semi: [2, "never"]

Then, the following patterns are considered problems:

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

var name = "ESLint";

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

And the following patterns are not considered problems:

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

var name = "ESLint"

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

Even in "never" mode, semicolons are still allowed to disambiguate statements beginning with [, (, /, +, or -:

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

var name = "ESLint"

;(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
• Understanding Automatic Semicolon Insertion in JavaScript

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/

            break;

Close

enforce consistent indentation (indent)

(fixable) The --fix option on the [command line](../user-guide/command-line-interface#fix) automatically fixes problems reported by this rule.

There are several common guidelines which require specific indentation of nested blocks and statements, like:

function hello(indentSize, type) {
    if (indentSize === 4 && type !== 'tab') {
        console.log('Each next indentation will increase on 4 spaces');
    }
}

These are the most common scenarios recommended in different style guides:

• Two spaces, not longer and no tabs: Google, npm, Node.js, Idiomatic, Felix
• Tabs: jQuery
• Four spaces: Crockford

Rule Details

This rule enforces a consistent indentation style. The default style is 4 spaces.

Options

This rule has a mixed option:

For example, for 2-space indentation:

{
    "indent": ["error", 2]
}

Or for tabbed indentation:

{
    "indent": ["error", "tab"]
}

Examples of incorrect code for this rule with the default options:

/*eslint indent: "error"*/

if (a) {
  b=c;
  function foo(d) {
    e=f;
  }
}

Examples of correct code for this rule with the default options:

/*eslint indent: "error"*/

if (a) {
    b=c;
    function foo(d) {
        e=f;
    }
}

This rule has an object option:

• "SwitchCase" (default: 0) enforces indentation level for case clauses in switch statements
• "VariableDeclarator" (default: 1) enforces indentation level for var declarators; can also take an object to define separate rules for var, let and const declarations.

Level of indentation denotes the multiple of the indent specified. Example:

• Indent of 4 spaces with VariableDeclarator set to 2 will indent the multi-line variable declarations with 8 spaces.
• Indent of 2 spaces with VariableDeclarator set to 2 will indent the multi-line variable declarations with 4 spaces.
• Indent of 2 spaces with VariableDeclarator set to {"var": 2, "let": 2, "const": 3} will indent the multi-line variable declarations with 4 spaces for var and let, 6 spaces for const statements.
• Indent of tab with VariableDeclarator set to 2 will indent the multi-line variable declarations with 2 tabs.
• Indent of 2 spaces with SwitchCase set to 0 will not indent case clauses with respect to switch statements.
• Indent of 2 spaces with SwitchCase set to 2 will indent case clauses with 4 spaces with respect to switch statements.
• Indent of tabs with SwitchCase set to 2 will indent case clauses with 2 tabs with respect to switch statements.

tab

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

/*eslint indent: ["error", "tab"]*/

if (a) {
     b=c;
function foo(d) {
           e=f;
 }
}

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

/*eslint indent: ["error", "tab"]*/

if (a) {
/*tab*/b=c;
/*tab*/function foo(d) {
/*tab*//*tab*/e=f;
/*tab*/}
}

SwitchCase

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

/*eslint indent: ["error", 2, { "SwitchCase": 1 }]*/

switch(a){
case "a":
    break;
case "b":
    break;
}

Examples of correct code for this rule with the 2, { "SwitchCase": 1 } option:

/*eslint indent: ["error", 2, { "SwitchCase": 1 }]*/

switch(a){
  case "a":
    break;
  case "b":
    break;
}

VariableDeclarator

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

/*eslint indent: ["error", 2, { "VariableDeclarator": 1 }]*/
/*eslint-env es6*/

var a,
    b,
    c;
let a,
    b,
    c;
const a = 1,
    b = 2,
    c = 3;

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

/*eslint indent: ["error", 2, { "VariableDeclarator": 1 }]*/
/*eslint-env es6*/

var a,
  b,
  c;
let a,
  b,
  c;
const a = 1,
  b = 2,
  c = 3;

Examples of correct code for this rule with the 2, { "VariableDeclarator": 2 } options:

/*eslint indent: ["error", 2, { "VariableDeclarator": 2 }]*/
/*eslint-env es6*/

var a,
    b,
    c;
let a,
    b,
    c;
const a = 1,
    b = 2,
    c = 3;

Examples of correct code for this rule with the 2, { "VariableDeclarator": { "var": 2, "let": 2, "const": 3 } } options:

/*eslint indent: ["error", 2, { "VariableDeclarator": { "var": 2, "let": 2, "const": 3 } }]*/
/*eslint-env es6*/

var a,
    b,
    c;
let a,
    b,
    c;
const a = 1,
      b = 2,
      c = 3;

Compatibility

• JSHint: indent
• JSCS: validateIndentation Source: http://eslint.org/docs/rules/

                data_.groups.sample.data[_caseIdIndex].cna_details.push(_cnaMetaIndex);

Close

enforce a maximum line length (max-len)

Very long lines of code in any language can be difficult to read. In order to aid in readability and maintainability many coders have developed a convention to limit lines of code to X number of characters (traditionally 80 characters).

var foo = { "bar": "This is a bar.", "baz": { "qux": "This is a qux" }, "difficult": "to read" }; // very long

Rule Details

This rule enforces a maximum line length to increase code readability and maintainability.

Note: This rule calculates the length of a line via code points, not characters. That means if you use a double-byte character in your code, it will count as 2 code points instead of 1, and 2 will be used to calculate line length. This is a technical limitation of JavaScript that is made easier with ES2015, and we will look to update this when ES2015 is available in Node.js.

Options

This rule has a number or object option:

• "code" (default 80) enforces a maximum line length
• "tabWidth" (default 4) specifies the character width for tab characters
• "comments" enforces a maximum line length for comments; defaults to value of code
• "ignorePattern" ignores lines matching a regular expression; can only match a single line and need to be double escaped when written in YAML or JSON
• "ignoreComments": true ignores all trailing comments and comments on their own line
• "ignoreTrailingComments": true ignores only trailing comments
• "ignoreUrls": true ignores lines that contain a URL

code

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

/*eslint max-len: ["error", 80]*/

var foo = { "bar": "This is a bar.", "baz": { "qux": "This is a qux" }, "difficult": "to read" };

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

/*eslint max-len: ["error", 80]*/

var foo = {
  "bar": "This is a bar.",
  "baz": { "qux": "This is a qux" },
  "easier": "to read"
};

tabWidth

Examples of incorrect code for this rule with the default { "tabWidth": 4 } option:

/*eslint max-len: ["error", 80, 4]*/

\t  \t  var foo = { "bar": "This is a bar.", "baz": { "qux": "This is a qux" } };

Examples of correct code for this rule with the default { "tabWidth": 4 } option:

/*eslint max-len: ["error", 80, 4]*/

\t  \t  var foo = {
\t  \t  \t  \t  "bar": "This is a bar.",
\t  \t  \t  \t  "baz": { "qux": "This is a qux" }
\t  \t  };

comments

Examples of incorrect code for this rule with the { "comments": 65 } option:

/*eslint max-len: ["error", { "comments": 65 }]*/

/**
 * This is a comment that violates the maximum line length we have specified
**/

ignoreComments

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

/*eslint max-len: ["error", { "ignoreComments": true }]*/

/**
 * This is a really really really really really really really really really long comment
**/

ignoreTrailingComments

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

/*eslint max-len: ["error", { "ignoreTrailingComments": true }]*/

var foo = 'bar'; // This is a really really really really really really really long comment

ignoreUrls

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

/*eslint max-len: ["error", { "ignoreUrls": true }]*/

var url = 'https://www.example.com/really/really/really/really/really/really/really/long';

ignorePattern

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

/*eslint max-len: ["error", { "ignorePattern": "^\\s*var\\s.+=\\s*require\\s*\\(/" }]*/

var dep = require('really/really/really/really/really/really/really/really/long/module');

Related Rules

• [complexity](complexity.md)
• [max-depth](max-depth.md)
• [max-nested-callbacks](max-nested-callbacks.md)
• [max-params](max-params.md)
• [max-statements](max-statements.md) Source: http://eslint.org/docs/rules/

      $.when(this.fetchCompleteData('patient', true), this.fetchCompleteData('sample', true)).then(function() {

Close

enforce a maximum line length (max-len)

Very long lines of code in any language can be difficult to read. In order to aid in readability and maintainability many coders have developed a convention to limit lines of code to X number of characters (traditionally 80 characters).

var foo = { "bar": "This is a bar.", "baz": { "qux": "This is a qux" }, "difficult": "to read" }; // very long

Rule Details

This rule enforces a maximum line length to increase code readability and maintainability.

Note: This rule calculates the length of a line via code points, not characters. That means if you use a double-byte character in your code, it will count as 2 code points instead of 1, and 2 will be used to calculate line length. This is a technical limitation of JavaScript that is made easier with ES2015, and we will look to update this when ES2015 is available in Node.js.

Options

This rule has a number or object option:

• "code" (default 80) enforces a maximum line length
• "tabWidth" (default 4) specifies the character width for tab characters
• "comments" enforces a maximum line length for comments; defaults to value of code
• "ignorePattern" ignores lines matching a regular expression; can only match a single line and need to be double escaped when written in YAML or JSON
• "ignoreComments": true ignores all trailing comments and comments on their own line
• "ignoreTrailingComments": true ignores only trailing comments
• "ignoreUrls": true ignores lines that contain a URL

code

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

/*eslint max-len: ["error", 80]*/

var foo = { "bar": "This is a bar.", "baz": { "qux": "This is a qux" }, "difficult": "to read" };

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

/*eslint max-len: ["error", 80]*/

var foo = {
  "bar": "This is a bar.",
  "baz": { "qux": "This is a qux" },
  "easier": "to read"
};

tabWidth

Examples of incorrect code for this rule with the default { "tabWidth": 4 } option:

/*eslint max-len: ["error", 80, 4]*/

\t  \t  var foo = { "bar": "This is a bar.", "baz": { "qux": "This is a qux" } };

Examples of correct code for this rule with the default { "tabWidth": 4 } option:

/*eslint max-len: ["error", 80, 4]*/

\t  \t  var foo = {
\t  \t  \t  \t  "bar": "This is a bar.",
\t  \t  \t  \t  "baz": { "qux": "This is a qux" }
\t  \t  };

comments

Examples of incorrect code for this rule with the { "comments": 65 } option:

/*eslint max-len: ["error", { "comments": 65 }]*/

/**
 * This is a comment that violates the maximum line length we have specified
**/

ignoreComments

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

/*eslint max-len: ["error", { "ignoreComments": true }]*/

/**
 * This is a really really really really really really really really really long comment
**/

ignoreTrailingComments

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

/*eslint max-len: ["error", { "ignoreTrailingComments": true }]*/

var foo = 'bar'; // This is a really really really really really really really long comment

ignoreUrls

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

/*eslint max-len: ["error", { "ignoreUrls": true }]*/

var url = 'https://www.example.com/really/really/really/really/really/really/really/long';

ignorePattern

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

/*eslint max-len: ["error", { "ignorePattern": "^\\s*var\\s.+=\\s*require\\s*\\(/" }]*/

var dep = require('really/really/really/really/really/really/really/really/long/module');

Related Rules

• [complexity](complexity.md)
• [max-depth](max-depth.md)
• [max-nested-callbacks](max-nested-callbacks.md)
• [max-params](max-params.md)
• [max-statements](max-statements.md) Source: http://eslint.org/docs/rules/

                  _.map(self.getStudyCacseIdsUsingUIDs('sample', filters_[attributes.attr_id]), function(item) {

Close

enforce a maximum line length (max-len)

Very long lines of code in any language can be difficult to read. In order to aid in readability and maintainability many coders have developed a convention to limit lines of code to X number of characters (traditionally 80 characters).

var foo = { "bar": "This is a bar.", "baz": { "qux": "This is a qux" }, "difficult": "to read" }; // very long

Rule Details

This rule enforces a maximum line length to increase code readability and maintainability.

Note: This rule calculates the length of a line via code points, not characters. That means if you use a double-byte character in your code, it will count as 2 code points instead of 1, and 2 will be used to calculate line length. This is a technical limitation of JavaScript that is made easier with ES2015, and we will look to update this when ES2015 is available in Node.js.

Options

This rule has a number or object option:

• "code" (default 80) enforces a maximum line length
• "tabWidth" (default 4) specifies the character width for tab characters
• "comments" enforces a maximum line length for comments; defaults to value of code
• "ignorePattern" ignores lines matching a regular expression; can only match a single line and need to be double escaped when written in YAML or JSON
• "ignoreComments": true ignores all trailing comments and comments on their own line
• "ignoreTrailingComments": true ignores only trailing comments
• "ignoreUrls": true ignores lines that contain a URL

code

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

/*eslint max-len: ["error", 80]*/

var foo = { "bar": "This is a bar.", "baz": { "qux": "This is a qux" }, "difficult": "to read" };

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

/*eslint max-len: ["error", 80]*/

var foo = {
  "bar": "This is a bar.",
  "baz": { "qux": "This is a qux" },
  "easier": "to read"
};

tabWidth

Examples of incorrect code for this rule with the default { "tabWidth": 4 } option:

/*eslint max-len: ["error", 80, 4]*/

\t  \t  var foo = { "bar": "This is a bar.", "baz": { "qux": "This is a qux" } };

Examples of correct code for this rule with the default { "tabWidth": 4 } option:

/*eslint max-len: ["error", 80, 4]*/

\t  \t  var foo = {
\t  \t  \t  \t  "bar": "This is a bar.",
\t  \t  \t  \t  "baz": { "qux": "This is a qux" }
\t  \t  };

comments

Examples of incorrect code for this rule with the { "comments": 65 } option:

/*eslint max-len: ["error", { "comments": 65 }]*/

/**
 * This is a comment that violates the maximum line length we have specified
**/

ignoreComments

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

/*eslint max-len: ["error", { "ignoreComments": true }]*/

/**
 * This is a really really really really really really really really really long comment
**/

ignoreTrailingComments

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

/*eslint max-len: ["error", { "ignoreTrailingComments": true }]*/

var foo = 'bar'; // This is a really really really really really really really long comment

ignoreUrls

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

/*eslint max-len: ["error", { "ignoreUrls": true }]*/

var url = 'https://www.example.com/really/really/really/really/really/really/really/long';

ignorePattern

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

/*eslint max-len: ["error", { "ignorePattern": "^\\s*var\\s.+=\\s*require\\s*\\(/" }]*/

var dep = require('really/really/really/really/really/really/really/really/long/module');

Related Rules

• [complexity](complexity.md)
• [max-depth](max-depth.md)
• [max-nested-callbacks](max-nested-callbacks.md)
• [max-params](max-params.md)
• [max-statements](max-statements.md) Source: http://eslint.org/docs/rules/

                _.each(caseList.allSampleIds, function(sampleId) {

Close

enforce a maximum depth that callbacks can be nested (max-nested-callbacks)

Many JavaScript libraries use the callback pattern to manage asynchronous operations. A program of any complexity will most likely need to manage several asynchronous operations at various levels of concurrency. A common pitfall that is easy to fall into is nesting callbacks, which makes code more difficult to read the deeper the callbacks are nested.

foo(function () {
    bar(function () {
        baz(function() {
            qux(function () {

            });
        });
    });
});

Rule Details

This rule enforces a maximum depth that callbacks can be nested to increase code clarity.

Options

This rule has a number or object option:

• "max" (default 10) enforces a maximum depth that callbacks can be nested

Deprecated: The object property maximum is deprecated; please use the object property max instead.

max

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

/*eslint max-nested-callbacks: ["error", 3]*/

foo1(function() {
    foo2(function() {
        foo3(function() {
            foo4(function() {
                // Do something
            });
        });
    });
});

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

/*eslint max-nested-callbacks: ["error", 3]*/

foo1(handleFoo1);

function handleFoo1() {
    foo2(handleFoo2);
}

function handleFoo2() {
    foo3(handleFoo3);
}

function handleFoo3() {
    foo4(handleFoo4);
}

function handleFoo4() {
    foo5();
}

Further Reading

• Control flow in Node.js
• Control Flow in Node
• Control Flow in Node Part II

Related Rules

• [complexity](complexity.md)
• [max-depth](max-depth.md)
• [max-len](max-len.md)
• [max-params](max-params.md)
• [max-statements](max-statements.md) Source: http://eslint.org/docs/rules/