Function priorityManager
has 71 lines of code (exceeds 25 allowed). Consider refactoring. Open
iViz.priorityManager = (function() {
var content = {};
var clinicalAttrsPriority = {};
var defaultPriority = 1;
Function getCombinationPriority
has 31 lines of code (exceeds 25 allowed). Consider refactoring. Open
function getCombinationPriority(id) {
var priority = _.clone(defaultPriority);
if (id) {
switch (id) {
case 'DFS_SURVIVAL':
Missing JSDoc return description. Open
/**
- Read upRead up
- Exclude checks
Validates JSDoc comments are syntactically correct (valid-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;
}
The JSDoc comments have a syntax all their own, and it is easy to mistakenly mistype a comment because comments aren't often checked for correctness in editors. Further, it's very easy for the function definition to get out of sync with the comments, making the comments a source of confusion and error.
Rule Details
This rule aims to prevent invalid and incomplete JSDoc comments. It will warn when any of the following is true:
- There is a JSDoc syntax error
- A
@param
or@returns
is used without a type specified - A
@param
or@returns
is used without a description - A comment for a function is missing
@returns
- A parameter has no associated
@param
in the JSDoc comment -
@param
s are out of order with named arguments
Examples of incorrect code for this rule:
/*eslint valid-jsdoc: "error"*/
// missing type for @param and missing @returns
/** // 2 errors
* A description
* @param num1 The first number.
*/
function foo(num1) {
// ...
}
// missing description for @param
/** //error Missing JSDoc parameter description for 'num1'.
* A description
* @param {int} num1
* @returns {void}
*/
function foo(num1) {
// ...
}
// no description for @returns
/** //error Missing JSDoc return description.
* A description
* @returns {int}
*/
function foo() {
// ...
}
// no type for @returns
/** //error JSDoc syntax error.
* A description
* @returns Something awesome
*/
function foo() {
// ...
}
// missing @param
/** //error Missing JSDoc for parameter 'a'.
* A description
* @returns {void}
*/
function foo(a) {
// ...
}
// incorrect @param
/** //error Expected JSDoc for 'a' but found 'b'.
* A description
* @param {string} b Desc
* @returns {void}
*/
function foo(a) {
// ...
}
Examples of correct code for this rule:
/*eslint valid-jsdoc: "error"*/
/**
* 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 foo(num1, num2) {
return num1 + num2;
}
/**
* Represents a sum.
* @param {int} num1 The first number.
* @param {int} num2 The second number.
* @constructor
*/
function foo(num1, num2) { }
// use of @override make @param and @returns optional
/**
* A description
* @override
*/
function foo(a) {
return a;
}
// @returns is not required for a constructor
class Foo {
/**
*
* @param {int} num1 The first number.
*/
constructor(num1) {
this.num1 = num1;
}
}
// @returns allowed without return if used with @abstract
class Foo {
/**
* @abstract
* @return {Number} num
*/
abstractMethod () {
throw new Error('Not implemented');
}
}
Options
prefer
JSDoc offers a lot of tags with overlapping meaning. For example, both @return
and @returns
are acceptable for specifying the return value of a function. However, you may want to enforce a certain tag be used instead of others. You can specify your preferences regarding tag substitution by providing a mapping called prefer
in the rule configuration. For example, to specify that @returns
should be used instead of @return
, you can use the following configuration:
"valid-jsdoc": ["error", {
"prefer": {
"return": "returns"
}
}]
With this configuration, ESLint will warn when it finds @return
and recommend to replace it with @returns
.
requireReturn
By default ESLint requires you to document every function with a @return
tag regardless of whether there is anything returned by the function. If instead you want to enforce that only functions with a return
statement are documented with a @return
tag, set the requireReturn
option to false
. When requireReturn
is false
, every function documented with a @return
tag must have a return
statement, and every function with a return
statement must have a @return
tag.
"valid-jsdoc": ["error", {
"requireReturn": false
}]
requireParamDescription
By default ESLint requires you to specify a description for each @param
. You can choose not to require descriptions for parameters by setting requireParamDescription
to false
.
"valid-jsdoc": ["error", {
"requireParamDescription": false
}]
requireReturnDescription
By default ESLint requires you to specify a description for each @return
. You can choose not to require descriptions for @return
by setting requireReturnDescription
to false
.
"valid-jsdoc": ["error", {
"requireReturnDescription": false
}]
matchDescription
Specify a regular expression to validate jsdoc comment block description against.
"valid-jsdoc": ["error", {
"matchDescription": "^[A-Z][A-Za-z0-9\\s]*[.]$"
}]
requireReturnType
By default ESLint requires you to specify type
for @return
tag for every documented function.
"valid-jsdoc": ["error", {
"requireReturnType": false
}]
preferType
It will validate all the types from jsdoc with the options setup by the user. Inside the options, key should be what the type you want to check and the value of it should be what the expected type should be. Note that we don't check for spelling mistakes with this option. In the example below, it will expect the "object" to start with an uppercase and all the "string" type to start with a lowercase.
"valid-jsdoc": ["error", {
"preferType": {
"String": "string",
"object": "Object",
"test": "TesT"
}
}]
Examples of incorrect code for a sample of "preferType"
options:
/*eslint valid-jsdoc: ["error", { "preferType": { "String": "string", "object": "Object", "test": "TesT" } }]*/
/**
* Adds two numbers together.
* @param {String} param1 The first parameter.
* @returns {object} The sum of the two numbers.
*/
function foo(param1) {
return {a: param1};
}
/**
* Adds two numbers together.
* @param {Array<string>} param1 The first parameter.
* @param {{1:test}} param2 The second parameter.
* @returns {object} The sum of the two numbers.
*/
function foo(param1, param2) {
return {a: param1};
}
/**
* Adds two numbers together.
* @param {String|int} param1 The first parameter.
* @returns {object} The sum of the two numbers.
*/
function foo(param1) {
return {a: param1};
}</string>
Examples of correct code for a sample of "preferType"
options:
/*eslint valid-jsdoc: ["error", { "preferType": { "String": "string", "object": "Object", "test": "TesT" } }]*/
/**
* Adds two numbers together.
* @param {string} param1 The first parameter.
* @returns {Object} The sum of the two numbers.
*/
function foo(param1) {
return {a: param1};
}
/**
* Adds two numbers together.
* @param {Array<string>} param1 The first parameter.
* @param {{1:TesT}} param2 The second parameter.
* @returns {Object} The sum of the two numbers.
*/
function foo(param1, param2) {
return {a: param1};
}
/**
* Adds two numbers together.
* @param {string|int} param1 The first parameter.
* @returns {Object} The sum of the two numbers.
*/
function foo(param1) {
return {a: param1};
}</string>
When Not To Use It
If you aren't using JSDoc, then you can safely turn this rule off.
Further Reading
- JSDoc Source: http://eslint.org/docs/rules/
["OS_SURVIVAL"] is better written in dot notation. Open
clinicalAttrsPriority['OS_SURVIVAL'];
- Read upRead up
- Exclude checks
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 tofalse
(default istrue
) 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/
["DFS_SURVIVAL"] is better written in dot notation. Open
clinicalAttrsPriority['DFS_SURVIVAL'];
- Read upRead up
- Exclude checks
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 tofalse
(default istrue
) 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/
["MUT_CNT_VS_CNA"] is better written in dot notation. Open
priority = clinicalAttrsPriority['MUT_CNT_VS_CNA'];
- Read upRead up
- Exclude checks
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 tofalse
(default istrue
) 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/
Missing JSDoc return description. Open
/**
- Read upRead up
- Exclude checks
Validates JSDoc comments are syntactically correct (valid-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;
}
The JSDoc comments have a syntax all their own, and it is easy to mistakenly mistype a comment because comments aren't often checked for correctness in editors. Further, it's very easy for the function definition to get out of sync with the comments, making the comments a source of confusion and error.
Rule Details
This rule aims to prevent invalid and incomplete JSDoc comments. It will warn when any of the following is true:
- There is a JSDoc syntax error
- A
@param
or@returns
is used without a type specified - A
@param
or@returns
is used without a description - A comment for a function is missing
@returns
- A parameter has no associated
@param
in the JSDoc comment -
@param
s are out of order with named arguments
Examples of incorrect code for this rule:
/*eslint valid-jsdoc: "error"*/
// missing type for @param and missing @returns
/** // 2 errors
* A description
* @param num1 The first number.
*/
function foo(num1) {
// ...
}
// missing description for @param
/** //error Missing JSDoc parameter description for 'num1'.
* A description
* @param {int} num1
* @returns {void}
*/
function foo(num1) {
// ...
}
// no description for @returns
/** //error Missing JSDoc return description.
* A description
* @returns {int}
*/
function foo() {
// ...
}
// no type for @returns
/** //error JSDoc syntax error.
* A description
* @returns Something awesome
*/
function foo() {
// ...
}
// missing @param
/** //error Missing JSDoc for parameter 'a'.
* A description
* @returns {void}
*/
function foo(a) {
// ...
}
// incorrect @param
/** //error Expected JSDoc for 'a' but found 'b'.
* A description
* @param {string} b Desc
* @returns {void}
*/
function foo(a) {
// ...
}
Examples of correct code for this rule:
/*eslint valid-jsdoc: "error"*/
/**
* 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 foo(num1, num2) {
return num1 + num2;
}
/**
* Represents a sum.
* @param {int} num1 The first number.
* @param {int} num2 The second number.
* @constructor
*/
function foo(num1, num2) { }
// use of @override make @param and @returns optional
/**
* A description
* @override
*/
function foo(a) {
return a;
}
// @returns is not required for a constructor
class Foo {
/**
*
* @param {int} num1 The first number.
*/
constructor(num1) {
this.num1 = num1;
}
}
// @returns allowed without return if used with @abstract
class Foo {
/**
* @abstract
* @return {Number} num
*/
abstractMethod () {
throw new Error('Not implemented');
}
}
Options
prefer
JSDoc offers a lot of tags with overlapping meaning. For example, both @return
and @returns
are acceptable for specifying the return value of a function. However, you may want to enforce a certain tag be used instead of others. You can specify your preferences regarding tag substitution by providing a mapping called prefer
in the rule configuration. For example, to specify that @returns
should be used instead of @return
, you can use the following configuration:
"valid-jsdoc": ["error", {
"prefer": {
"return": "returns"
}
}]
With this configuration, ESLint will warn when it finds @return
and recommend to replace it with @returns
.
requireReturn
By default ESLint requires you to document every function with a @return
tag regardless of whether there is anything returned by the function. If instead you want to enforce that only functions with a return
statement are documented with a @return
tag, set the requireReturn
option to false
. When requireReturn
is false
, every function documented with a @return
tag must have a return
statement, and every function with a return
statement must have a @return
tag.
"valid-jsdoc": ["error", {
"requireReturn": false
}]
requireParamDescription
By default ESLint requires you to specify a description for each @param
. You can choose not to require descriptions for parameters by setting requireParamDescription
to false
.
"valid-jsdoc": ["error", {
"requireParamDescription": false
}]
requireReturnDescription
By default ESLint requires you to specify a description for each @return
. You can choose not to require descriptions for @return
by setting requireReturnDescription
to false
.
"valid-jsdoc": ["error", {
"requireReturnDescription": false
}]
matchDescription
Specify a regular expression to validate jsdoc comment block description against.
"valid-jsdoc": ["error", {
"matchDescription": "^[A-Z][A-Za-z0-9\\s]*[.]$"
}]
requireReturnType
By default ESLint requires you to specify type
for @return
tag for every documented function.
"valid-jsdoc": ["error", {
"requireReturnType": false
}]
preferType
It will validate all the types from jsdoc with the options setup by the user. Inside the options, key should be what the type you want to check and the value of it should be what the expected type should be. Note that we don't check for spelling mistakes with this option. In the example below, it will expect the "object" to start with an uppercase and all the "string" type to start with a lowercase.
"valid-jsdoc": ["error", {
"preferType": {
"String": "string",
"object": "Object",
"test": "TesT"
}
}]
Examples of incorrect code for a sample of "preferType"
options:
/*eslint valid-jsdoc: ["error", { "preferType": { "String": "string", "object": "Object", "test": "TesT" } }]*/
/**
* Adds two numbers together.
* @param {String} param1 The first parameter.
* @returns {object} The sum of the two numbers.
*/
function foo(param1) {
return {a: param1};
}
/**
* Adds two numbers together.
* @param {Array<string>} param1 The first parameter.
* @param {{1:test}} param2 The second parameter.
* @returns {object} The sum of the two numbers.
*/
function foo(param1, param2) {
return {a: param1};
}
/**
* Adds two numbers together.
* @param {String|int} param1 The first parameter.
* @returns {object} The sum of the two numbers.
*/
function foo(param1) {
return {a: param1};
}</string>
Examples of correct code for a sample of "preferType"
options:
/*eslint valid-jsdoc: ["error", { "preferType": { "String": "string", "object": "Object", "test": "TesT" } }]*/
/**
* Adds two numbers together.
* @param {string} param1 The first parameter.
* @returns {Object} The sum of the two numbers.
*/
function foo(param1) {
return {a: param1};
}
/**
* Adds two numbers together.
* @param {Array<string>} param1 The first parameter.
* @param {{1:TesT}} param2 The second parameter.
* @returns {Object} The sum of the two numbers.
*/
function foo(param1, param2) {
return {a: param1};
}
/**
* Adds two numbers together.
* @param {string|int} param1 The first parameter.
* @returns {Object} The sum of the two numbers.
*/
function foo(param1) {
return {a: param1};
}</string>
When Not To Use It
If you aren't using JSDoc, then you can safely turn this rule off.
Further Reading
- JSDoc Source: http://eslint.org/docs/rules/
Expected a default case. Open
switch (id) {
- Read upRead up
- Exclude checks
Require Default Case in Switch Statements (default-case)
Some code conventions require that all switch
statements have a default
case, even if the default case is empty, such as:
switch (foo) {
case 1:
doSomething();
break;
case 2:
doSomething();
break;
default:
// do nothing
}
The thinking is that it's better to always explicitly state what the default behavior should be so that it's clear whether or not the developer forgot to include the default behavior by mistake.
Other code conventions allow you to skip the default
case so long as there is a comment indicating the omission is intentional, such as:
switch (foo) {
case 1:
doSomething();
break;
case 2:
doSomething();
break;
// no default
}
Once again, the intent here is to show that the developer intended for there to be no default behavior.
Rule Details
This rule aims to require default
case in switch
statements. You may optionally include a // no default
after the last case
if there is no default
case.
Examples of incorrect code for this rule:
/*eslint default-case: "error"*/
switch (a) {
case 1:
/* code */
break;
}
Examples of correct code for this rule:
/*eslint default-case: "error"*/
switch (a) {
case 1:
/* code */
break;
default:
/* code */
break;
}
switch (a) {
case 1:
/* code */
break;
// no default
}
Options
This rule accepts a single options argument:
- Set the
commentPattern
option to a regular expression string to change the default^no default$
comment test pattern
commentPattern
Examples of correct code for the { "commentPattern": "^skip\\sdefault" }
option:
/*eslint default-case: ["error", { "commentPattern": "^skip\\sdefault" }]*/
switch(a) {
case 1:
/* code */
break;
// skip default
}
switch(a) {
case 1:
/* code */
break;
// skip default case
}
When Not To Use It
If you don't want to enforce a default
case for switch
statements, you can safely disable this rule.
Related Rules
- [no-fallthrough](no-fallthrough.md) Source: http://eslint.org/docs/rules/
Similar blocks of code found in 2 locations. Consider refactoring. Open
case 'OS_SURVIVAL':
var _osStatus = getPriority('OS_STATUS');
var _osMonths = getPriority('OS_MONTHS');
if (_osStatus === 0 || _osMonths === 0) {
priority = 0;
- Read upRead up
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 93.
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
Similar blocks of code found in 2 locations. Consider refactoring. Open
case 'DFS_SURVIVAL':
var _dfsStatus = getPriority('DFS_STATUS');
var _dfsMonths = getPriority('DFS_MONTHS');
if (_dfsStatus === 0 || _dfsMonths === 0) {
priority = 0;
- Read upRead up
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 93.
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
More than 1 blank line not allowed. Open
- Read upRead up
- Exclude checks
Disallows multiple blank lines (no-multiple-empty-lines)
Some developers prefer to have multiple blank lines removed, while others feel that it helps improve readability. Whitespace is useful for separating logical sections of code, but excess whitespace takes up more of the screen.
Rule Details
This rule aims to reduce the scrolling required when reading through your code. It will warn when the maximum amount of empty lines has been exceeded.
Options
The second argument can be used to configure this rule:
-
max
sets the maximum number of consecutive blank lines. -
maxEOF
can be used to set a different number for the end of file. The last blank lines will then be treated differently. If omitted, themax
option is applied at the end of the file. -
maxBOF
can be used to set a different number for the beginning of the file. If omitted, the 'max' option is applied at the beginning of the file.
max
In the following example, the error
is the severity of the rule, and the
max
property is the maximum number of empty lines (2 in this example).
"no-multiple-empty-lines": ["error", {"max": 2}]
The following patterns are considered problems:
/*eslint no-multiple-empty-lines: ["error", {max: 2}]*/
var foo = 5;
var bar = 3;
The following patterns are not considered problems:
/*eslint no-multiple-empty-lines: ["error", {max: 2}]*/
var foo = 5;
var bar = 3;
maxEOF
"no-multiple-empty-lines": ["error", {"max": 2, "maxEOF": 1}]
The following patterns are considered problems:
/*eslint no-multiple-empty-lines: ["error", {max: 2, maxEOF: 1}]*/
var foo = 5;
var bar = 3;
The following patterns are not considered problems:
/*eslint no-multiple-empty-lines: ["error", {max: 2, maxEOF: 1}]*/
var foo = 5;
var bar = 3;
maxBOF
"no-multiple-empty-lines": ["error", {"max": 2, "maxBOF": 0}]
The following patterns are considered problems:
/*eslint no-multiple-empty-lines: ["error", {max: 2, maxBOF: 0}]*/
var foo = 5;
var bar = 3;
The following patterns are not considered problems:
/*eslint no-multiple-empty-lines: ["error", {max: 2, maxBOF: 0}]*/
var foo = 5;
var bar = 3;
When Not To Use It
If you do not care about extra blank lines, turn this off. Source: http://eslint.org/docs/rules/
Expected indentation of 12 space characters but found 10. Open
break;
- Read upRead up
- Exclude checks
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 forcase
clauses inswitch
statements -
"VariableDeclarator"
(default: 1) enforces indentation level forvar
declarators; can also take an object to define separate rules forvar
,let
andconst
declarations.
Level of indentation denotes the multiple of the indent specified. Example:
- Indent of 4 spaces with
VariableDeclarator
set to2
will indent the multi-line variable declarations with 8 spaces. - Indent of 2 spaces with
VariableDeclarator
set to2
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 forvar
andlet
, 6 spaces forconst
statements. - Indent of tab with
VariableDeclarator
set to2
will indent the multi-line variable declarations with 2 tabs. - Indent of 2 spaces with
SwitchCase
set to0
will not indentcase
clauses with respect toswitch
statements. - Indent of 2 spaces with
SwitchCase
set to2
will indentcase
clauses with 4 spaces with respect toswitch
statements. - Indent of tabs with
SwitchCase
set to2
will indentcase
clauses with 2 tabs with respect toswitch
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/
Expected indentation of 12 space characters but found 10. Open
priority = clinicalAttrsPriority['MUT_CNT_VS_CNA'];
- Read upRead up
- Exclude checks
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 forcase
clauses inswitch
statements -
"VariableDeclarator"
(default: 1) enforces indentation level forvar
declarators; can also take an object to define separate rules forvar
,let
andconst
declarations.
Level of indentation denotes the multiple of the indent specified. Example:
- Indent of 4 spaces with
VariableDeclarator
set to2
will indent the multi-line variable declarations with 8 spaces. - Indent of 2 spaces with
VariableDeclarator
set to2
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 forvar
andlet
, 6 spaces forconst
statements. - Indent of tab with
VariableDeclarator
set to2
will indent the multi-line variable declarations with 2 tabs. - Indent of 2 spaces with
SwitchCase
set to0
will not indentcase
clauses with respect toswitch
statements. - Indent of 2 spaces with
SwitchCase
set to2
will indentcase
clauses with 4 spaces with respect toswitch
statements. - Indent of tabs with
SwitchCase
set to2
will indentcase
clauses with 2 tabs with respect toswitch
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/
There should be no spaces inside this paren. Open
priority = (_dfsMonths + _dfsStatus ) / 2;
- Read upRead up
- Exclude checks
Disallow or enforce spaces inside of parentheses (space-in-parens)
(fixable) The --fix
option on the [command line](../user-guide/command-line-interface#fix) automatically fixes problems reported by this rule.
Some style guides require or disallow spaces inside of parentheses:
foo( 'bar' );
var x = ( 1 + 2 ) * 3;
foo('bar');
var x = (1 + 2) * 3;
Rule Details
This rule will enforce consistency of spacing directly inside of parentheses, by disallowing or requiring one or more spaces to the right of (
and to the left of )
. In either case, ()
will still be allowed.
Options
There are two options for this rule:
-
"always"
enforces a space inside of parentheses -
"never"
enforces zero spaces inside of parentheses (default)
Depending on your coding conventions, you can choose either option by specifying it in your configuration:
"space-in-parens": ["error", "always"]
"always"
When "always"
is set, the following patterns are considered problems:
/*eslint space-in-parens: ["error", "always"]*/
foo( 'bar');
foo('bar' );
foo('bar');
var foo = (1 + 2) * 3;
(function () { return 'bar'; }());
The following patterns are not considered problems:
/*eslint space-in-parens: ["error", "always"]*/
foo();
foo( 'bar' );
var foo = ( 1 + 2 ) * 3;
( function () { return 'bar'; }() );
"never"
When "never"
is used, the following patterns are considered problems:
/*eslint space-in-parens: ["error", "never"]*/
foo( 'bar');
foo('bar' );
foo( 'bar' );
var foo = ( 1 + 2 ) * 3;
( function () { return 'bar'; }() );
The following patterns are not considered problems:
/*eslint space-in-parens: ["error", "never"]*/
foo();
foo('bar');
var foo = (1 + 2) * 3;
(function () { return 'bar'; }());
Exceptions
An object literal may be used as a third array item to specify exceptions, with the key "exceptions"
and an array as the value. These exceptions work in the context of the first option. That is, if "always"
is set to enforce spacing, then any "exception" will disallow spacing. Conversely, if "never"
is set to disallow spacing, then any "exception" will enforce spacing.
The following exceptions are available: ["{}", "[]", "()", "empty"]
.
For example, given "space-in-parens": ["error", "always", { "exceptions": ["{}"] }]
, the following patterns are considered problems:
/*eslint space-in-parens: ["error", "always", { "exceptions": ["{}"] }]*/
foo( {bar: 'baz'} );
foo( 1, {bar: 'baz'} );
The following patterns are not considered problems:
/*eslint space-in-parens: ["error", "always", { "exceptions": ["{}"] }]*/
foo({bar: 'baz'});
foo( 1, {bar: 'baz'});
Or, given "space-in-parens": ["error", "never", { "exceptions": ["{}"] }]
, the following patterns are considered problems:
/*eslint space-in-parens: ["error", "never", { "exceptions": ["{}"] }]*/
foo({bar: 'baz'});
foo(1, {bar: 'baz'});
The following patterns are not considered problems:
/*eslint space-in-parens: ["error", "never", { "exceptions": ["{}"] }]*/
foo( {bar: 'baz'} );
foo(1, {bar: 'baz'} );
Given "space-in-parens": ["error", "always", { "exceptions": ["[]"] }]
, the following patterns are considered problems:
/*eslint space-in-parens: ["error", "always", { "exceptions": ["[]"] }]*/
foo( [bar, baz] );
foo( [bar, baz], 1 );
The following patterns are not considered problems:
/*eslint space-in-parens: ["error", "always", { "exceptions": ["[]"] }]*/
foo([bar, baz]);
foo([bar, baz], 1 );
Or, given "space-in-parens": ["error", "never", { "exceptions": ["[]"] }]
, the following patterns are considered problems:
/*eslint space-in-parens: ["error", "never", { "exceptions": ["[]"] }]*/
foo([bar, baz]);
foo([bar, baz], 1);
The following patterns are not considered problems:
/*eslint space-in-parens: ["error", "never", { "exceptions": ["[]"] }]*/
foo( [bar, baz] );
foo( [bar, baz], 1);
Given "space-in-parens": ["error", "always", { "exceptions": ["()"] }]
, the following patterns are considered problems:
/*eslint space-in-parens: ["error", "always", { "exceptions": ["()"] }]*/
foo( ( 1 + 2 ) );
foo( ( 1 + 2 ), 1 );
The following patterns are not considered problems:
/*eslint space-in-parens: ["error", "always", { "exceptions": ["()"] }]*/
foo(( 1 + 2 ));
foo(( 1 + 2 ), 1 );
Or, given "space-in-parens": ["error", "never", { "exceptions": ["()"] }]
, the following patterns are considered problems:
/*eslint space-in-parens: ["error", "never", { "exceptions": ["()"] }]*/
foo((1 + 2));
foo((1 + 2), 1);
The following patterns are not considered problems:
/*eslint space-in-parens: ["error", "never", { "exceptions": ["()"] }]*/
foo( (1 + 2) );
foo( (1 + 2), 1);
The "empty"
exception concerns empty parentheses, and works the same way as the other exceptions, inverting the first option.
For example, given "space-in-parens": ["error", "always", { "exceptions": ["empty"] }]
, the following patterns are considered problems:
/*eslint space-in-parens: ["error", "always", { "exceptions": ["empty"] }]*/
foo( );
The following patterns are not considered problems:
/*eslint space-in-parens: ["error", "always", { "exceptions": ["empty"] }]*/
foo();
Or, given "space-in-parens": ["error", "never", { "exceptions": ["empty"] }]
, the following patterns are considered problems:
/*eslint space-in-parens: ["error", "never", { "exceptions": ["empty"] }]*/
foo();
The following patterns are not considered problems:
/*eslint space-in-parens: ["error", "never", { "exceptions": ["empty"] }]*/
foo( );
You can include multiple entries in the "exceptions"
array. For example, given "space-in-parens": ["error", "always", { "exceptions": ["{}", "[]"] }]
, the following patterns are considered problems:
/*eslint space-in-parens: ["error", "always", { "exceptions": ["{}", "[]"] }]*/
bar( {bar:'baz'} );
baz( 1, [1,2] );
foo( {bar: 'baz'}, [1, 2] );
The following patterns are not considered problems:
/*eslint space-in-parens: ["error", "always", { "exceptions": ["{}", "[]"] }]*/
bar({bar:'baz'});
baz( 1, [1,2]);
foo({bar: 'baz'}, [1, 2]);
When Not To Use It
You can turn this rule off if you are not concerned with the consistency of spacing between parentheses.
Related Rules
- [space-in-brackets](space-in-brackets.md) (deprecated) Source: http://eslint.org/docs/rules/
Expected indentation of 12 space characters but found 10. Open
var _osStatus = getPriority('OS_STATUS');
- Read upRead up
- Exclude checks
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 forcase
clauses inswitch
statements -
"VariableDeclarator"
(default: 1) enforces indentation level forvar
declarators; can also take an object to define separate rules forvar
,let
andconst
declarations.
Level of indentation denotes the multiple of the indent specified. Example:
- Indent of 4 spaces with
VariableDeclarator
set to2
will indent the multi-line variable declarations with 8 spaces. - Indent of 2 spaces with
VariableDeclarator
set to2
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 forvar
andlet
, 6 spaces forconst
statements. - Indent of tab with
VariableDeclarator
set to2
will indent the multi-line variable declarations with 2 tabs. - Indent of 2 spaces with
SwitchCase
set to0
will not indentcase
clauses with respect toswitch
statements. - Indent of 2 spaces with
SwitchCase
set to2
will indentcase
clauses with 4 spaces with respect toswitch
statements. - Indent of tabs with
SwitchCase
set to2
will indentcase
clauses with 2 tabs with respect toswitch
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/
Expected indentation of 12 space characters but found 10. Open
var _osMonths = getPriority('OS_MONTHS');
- Read upRead up
- Exclude checks
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 forcase
clauses inswitch
statements -
"VariableDeclarator"
(default: 1) enforces indentation level forvar
declarators; can also take an object to define separate rules forvar
,let
andconst
declarations.
Level of indentation denotes the multiple of the indent specified. Example:
- Indent of 4 spaces with
VariableDeclarator
set to2
will indent the multi-line variable declarations with 8 spaces. - Indent of 2 spaces with
VariableDeclarator
set to2
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 forvar
andlet
, 6 spaces forconst
statements. - Indent of tab with
VariableDeclarator
set to2
will indent the multi-line variable declarations with 2 tabs. - Indent of 2 spaces with
SwitchCase
set to0
will not indentcase
clauses with respect toswitch
statements. - Indent of 2 spaces with
SwitchCase
set to2
will indentcase
clauses with 4 spaces with respect toswitch
statements. - Indent of tabs with
SwitchCase
set to2
will indentcase
clauses with 2 tabs with respect toswitch
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/
There should be no spaces inside this paren. Open
priority = (_osStatus + _osMonths ) / 2;
- Read upRead up
- Exclude checks
Disallow or enforce spaces inside of parentheses (space-in-parens)
(fixable) The --fix
option on the [command line](../user-guide/command-line-interface#fix) automatically fixes problems reported by this rule.
Some style guides require or disallow spaces inside of parentheses:
foo( 'bar' );
var x = ( 1 + 2 ) * 3;
foo('bar');
var x = (1 + 2) * 3;
Rule Details
This rule will enforce consistency of spacing directly inside of parentheses, by disallowing or requiring one or more spaces to the right of (
and to the left of )
. In either case, ()
will still be allowed.
Options
There are two options for this rule:
-
"always"
enforces a space inside of parentheses -
"never"
enforces zero spaces inside of parentheses (default)
Depending on your coding conventions, you can choose either option by specifying it in your configuration:
"space-in-parens": ["error", "always"]
"always"
When "always"
is set, the following patterns are considered problems:
/*eslint space-in-parens: ["error", "always"]*/
foo( 'bar');
foo('bar' );
foo('bar');
var foo = (1 + 2) * 3;
(function () { return 'bar'; }());
The following patterns are not considered problems:
/*eslint space-in-parens: ["error", "always"]*/
foo();
foo( 'bar' );
var foo = ( 1 + 2 ) * 3;
( function () { return 'bar'; }() );
"never"
When "never"
is used, the following patterns are considered problems:
/*eslint space-in-parens: ["error", "never"]*/
foo( 'bar');
foo('bar' );
foo( 'bar' );
var foo = ( 1 + 2 ) * 3;
( function () { return 'bar'; }() );
The following patterns are not considered problems:
/*eslint space-in-parens: ["error", "never"]*/
foo();
foo('bar');
var foo = (1 + 2) * 3;
(function () { return 'bar'; }());
Exceptions
An object literal may be used as a third array item to specify exceptions, with the key "exceptions"
and an array as the value. These exceptions work in the context of the first option. That is, if "always"
is set to enforce spacing, then any "exception" will disallow spacing. Conversely, if "never"
is set to disallow spacing, then any "exception" will enforce spacing.
The following exceptions are available: ["{}", "[]", "()", "empty"]
.
For example, given "space-in-parens": ["error", "always", { "exceptions": ["{}"] }]
, the following patterns are considered problems:
/*eslint space-in-parens: ["error", "always", { "exceptions": ["{}"] }]*/
foo( {bar: 'baz'} );
foo( 1, {bar: 'baz'} );
The following patterns are not considered problems:
/*eslint space-in-parens: ["error", "always", { "exceptions": ["{}"] }]*/
foo({bar: 'baz'});
foo( 1, {bar: 'baz'});
Or, given "space-in-parens": ["error", "never", { "exceptions": ["{}"] }]
, the following patterns are considered problems:
/*eslint space-in-parens: ["error", "never", { "exceptions": ["{}"] }]*/
foo({bar: 'baz'});
foo(1, {bar: 'baz'});
The following patterns are not considered problems:
/*eslint space-in-parens: ["error", "never", { "exceptions": ["{}"] }]*/
foo( {bar: 'baz'} );
foo(1, {bar: 'baz'} );
Given "space-in-parens": ["error", "always", { "exceptions": ["[]"] }]
, the following patterns are considered problems:
/*eslint space-in-parens: ["error", "always", { "exceptions": ["[]"] }]*/
foo( [bar, baz] );
foo( [bar, baz], 1 );
The following patterns are not considered problems:
/*eslint space-in-parens: ["error", "always", { "exceptions": ["[]"] }]*/
foo([bar, baz]);
foo([bar, baz], 1 );
Or, given "space-in-parens": ["error", "never", { "exceptions": ["[]"] }]
, the following patterns are considered problems:
/*eslint space-in-parens: ["error", "never", { "exceptions": ["[]"] }]*/
foo([bar, baz]);
foo([bar, baz], 1);
The following patterns are not considered problems:
/*eslint space-in-parens: ["error", "never", { "exceptions": ["[]"] }]*/
foo( [bar, baz] );
foo( [bar, baz], 1);
Given "space-in-parens": ["error", "always", { "exceptions": ["()"] }]
, the following patterns are considered problems:
/*eslint space-in-parens: ["error", "always", { "exceptions": ["()"] }]*/
foo( ( 1 + 2 ) );
foo( ( 1 + 2 ), 1 );
The following patterns are not considered problems:
/*eslint space-in-parens: ["error", "always", { "exceptions": ["()"] }]*/
foo(( 1 + 2 ));
foo(( 1 + 2 ), 1 );
Or, given "space-in-parens": ["error", "never", { "exceptions": ["()"] }]
, the following patterns are considered problems:
/*eslint space-in-parens: ["error", "never", { "exceptions": ["()"] }]*/
foo((1 + 2));
foo((1 + 2), 1);
The following patterns are not considered problems:
/*eslint space-in-parens: ["error", "never", { "exceptions": ["()"] }]*/
foo( (1 + 2) );
foo( (1 + 2), 1);
The "empty"
exception concerns empty parentheses, and works the same way as the other exceptions, inverting the first option.
For example, given "space-in-parens": ["error", "always", { "exceptions": ["empty"] }]
, the following patterns are considered problems:
/*eslint space-in-parens: ["error", "always", { "exceptions": ["empty"] }]*/
foo( );
The following patterns are not considered problems:
/*eslint space-in-parens: ["error", "always", { "exceptions": ["empty"] }]*/
foo();
Or, given "space-in-parens": ["error", "never", { "exceptions": ["empty"] }]
, the following patterns are considered problems:
/*eslint space-in-parens: ["error", "never", { "exceptions": ["empty"] }]*/
foo();
The following patterns are not considered problems:
/*eslint space-in-parens: ["error", "never", { "exceptions": ["empty"] }]*/
foo( );
You can include multiple entries in the "exceptions"
array. For example, given "space-in-parens": ["error", "always", { "exceptions": ["{}", "[]"] }]
, the following patterns are considered problems:
/*eslint space-in-parens: ["error", "always", { "exceptions": ["{}", "[]"] }]*/
bar( {bar:'baz'} );
baz( 1, [1,2] );
foo( {bar: 'baz'}, [1, 2] );
The following patterns are not considered problems:
/*eslint space-in-parens: ["error", "always", { "exceptions": ["{}", "[]"] }]*/
bar({bar:'baz'});
baz( 1, [1,2]);
foo({bar: 'baz'}, [1, 2]);
When Not To Use It
You can turn this rule off if you are not concerned with the consistency of spacing between parentheses.
Related Rules
- [space-in-brackets](space-in-brackets.md) (deprecated) Source: http://eslint.org/docs/rules/
Expected indentation of 12 space characters but found 10. Open
break;
- Read upRead up
- Exclude checks
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 forcase
clauses inswitch
statements -
"VariableDeclarator"
(default: 1) enforces indentation level forvar
declarators; can also take an object to define separate rules forvar
,let
andconst
declarations.
Level of indentation denotes the multiple of the indent specified. Example:
- Indent of 4 spaces with
VariableDeclarator
set to2
will indent the multi-line variable declarations with 8 spaces. - Indent of 2 spaces with
VariableDeclarator
set to2
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 forvar
andlet
, 6 spaces forconst
statements. - Indent of tab with
VariableDeclarator
set to2
will indent the multi-line variable declarations with 2 tabs. - Indent of 2 spaces with
SwitchCase
set to0
will not indentcase
clauses with respect toswitch
statements. - Indent of 2 spaces with
SwitchCase
set to2
will indentcase
clauses with 4 spaces with respect toswitch
statements. - Indent of tabs with
SwitchCase
set to2
will indentcase
clauses with 2 tabs with respect toswitch
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/
'?' should be placed at the end of the line. Open
? clinicalAttrsPriority[id] : 1;
- Read upRead up
- Exclude checks
Operator Linebreak (operator-linebreak)
When a statement is too long to fit on a single line, line breaks are generally inserted next to the operators separating expressions. The first style coming to mind would be to place the operator at the end of the line, following the english punctuation rules.
var fullHeight = borderTop +
innerHeight +
borderBottom;
Some developers find that placing operators at the beginning of the line makes the code more readable.
var fullHeight = borderTop
+ innerHeight
+ borderBottom;
Rule Details
The operator-linebreak
rule is aimed at enforcing a particular operator line break style. As such, it warns whenever it sees a binary operator or assignment that does not adhere to a particular style: either placing linebreaks after or before the operators.
Options
The rule takes two options, a string, which can be "after"
, "before"
or "none"
where the default is "after"
and an object for more fine-grained configuration.
You can set the style in configuration like this:
"operator-linebreak": ["error", "before", { "overrides": { "?": "after" } }]
The default configuration is to enforce line breaks after the operator except for the ternary operator ?
and :
following that.
"after"
This is the default setting for this rule. This option requires the line break to be placed after the operator.
While using this setting, the following patterns are considered problems:
/*eslint operator-linebreak: ["error", "after"]*/
foo = 1
+
2;
foo = 1
+ 2;
foo
= 5;
if (someCondition
|| otherCondition) {
}
answer = everything
? 42
: foo;
The following patterns are not considered problems:
/*eslint operator-linebreak: ["error", "after"]*/
foo = 1 + 2;
foo = 1 +
2;
foo =
5;
if (someCondition ||
otherCondition) {
}
answer = everything ?
42 :
foo;
"before"
This option requires the line break to be placed before the operator.
While using this setting, the following patterns are considered problems:
/*eslint operator-linebreak: ["error", "before"]*/
foo = 1 +
2;
foo =
5;
if (someCondition ||
otherCondition) {
}
answer = everything ?
42 :
foo;
The following patterns are not considered problems:
/*eslint operator-linebreak: ["error", "before"]*/
foo = 1 + 2;
foo = 1
+ 2;
foo
= 5;
if (someCondition
|| otherCondition) {
}
answer = everything
? 42
: foo;
"none"
This option disallows line breaks on either side of the operator.
While using this setting, the following patterns are considered problems:
/*eslint operator-linebreak: ["error", "none"]*/
foo = 1 +
2;
foo = 1
+ 2;
if (someCondition ||
otherCondition) {
}
if (someCondition
|| otherCondition) {
}
answer = everything
? 42
: foo;
answer = everything ?
42 :
foo;
The following patterns are not considered problems:
/*eslint operator-linebreak: ["error", "none"]*/
foo = 1 + 2;
foo = 5;
if (someCondition || otherCondition) {
}
answer = everything ? 42 : foo;
Fine-grained control
The rule allows you to have even finer-grained control over individual operators by specifying an overrides
dictionary:
"operator-linebreak": ["error", "before", { "overrides": { "?": "after", "+=": "none" } }]
This would override the global setting for that specific operator.
"ignore" override
This option is only supported using overrides and ignores line breaks on either side of the operator.
While using this setting, the following patterns are not considered problems:
/*eslint operator-linebreak: ["error", "after", { "overrides": { "?": "ignore", ":": "ignore"} }]*/
answer = everything ?
42
: foo;
answer = everything
?
42
:
foo;
When Not To Use It
If your project will not be using a common operator line break style, turn this rule off.
Related Rules
- [comma-style](comma-style.md) Source: http://eslint.org/docs/rules/
Expected indentation of 12 space characters but found 10. Open
var _dfsMonths = getPriority('DFS_MONTHS');
- Read upRead up
- Exclude checks
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 forcase
clauses inswitch
statements -
"VariableDeclarator"
(default: 1) enforces indentation level forvar
declarators; can also take an object to define separate rules forvar
,let
andconst
declarations.
Level of indentation denotes the multiple of the indent specified. Example:
- Indent of 4 spaces with
VariableDeclarator
set to2
will indent the multi-line variable declarations with 8 spaces. - Indent of 2 spaces with
VariableDeclarator
set to2
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 forvar
andlet
, 6 spaces forconst
statements. - Indent of tab with
VariableDeclarator
set to2
will indent the multi-line variable declarations with 2 tabs. - Indent of 2 spaces with
SwitchCase
set to0
will not indentcase
clauses with respect toswitch
statements. - Indent of 2 spaces with
SwitchCase
set to2
will indentcase
clauses with 4 spaces with respect toswitch
statements. - Indent of tabs with
SwitchCase
set to2
will indentcase
clauses with 2 tabs with respect toswitch
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/
Expected indentation of 12 space characters but found 10. Open
break;
- Read upRead up
- Exclude checks
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 forcase
clauses inswitch
statements -
"VariableDeclarator"
(default: 1) enforces indentation level forvar
declarators; can also take an object to define separate rules forvar
,let
andconst
declarations.
Level of indentation denotes the multiple of the indent specified. Example:
- Indent of 4 spaces with
VariableDeclarator
set to2
will indent the multi-line variable declarations with 8 spaces. - Indent of 2 spaces with
VariableDeclarator
set to2
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 forvar
andlet
, 6 spaces forconst
statements. - Indent of tab with
VariableDeclarator
set to2
will indent the multi-line variable declarations with 2 tabs. - Indent of 2 spaces with
SwitchCase
set to0
will not indentcase
clauses with respect toswitch
statements. - Indent of 2 spaces with
SwitchCase
set to2
will indentcase
clauses with 4 spaces with respect toswitch
statements. - Indent of tabs with
SwitchCase
set to2
will indentcase
clauses with 2 tabs with respect toswitch
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/
Expected indentation of 10 space characters but found 8. Open
case 'OS_SURVIVAL':
- Read upRead up
- Exclude checks
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 forcase
clauses inswitch
statements -
"VariableDeclarator"
(default: 1) enforces indentation level forvar
declarators; can also take an object to define separate rules forvar
,let
andconst
declarations.
Level of indentation denotes the multiple of the indent specified. Example:
- Indent of 4 spaces with
VariableDeclarator
set to2
will indent the multi-line variable declarations with 8 spaces. - Indent of 2 spaces with
VariableDeclarator
set to2
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 forvar
andlet
, 6 spaces forconst
statements. - Indent of tab with
VariableDeclarator
set to2
will indent the multi-line variable declarations with 2 tabs. - Indent of 2 spaces with
SwitchCase
set to0
will not indentcase
clauses with respect toswitch
statements. - Indent of 2 spaces with
SwitchCase
set to2
will indentcase
clauses with 4 spaces with respect toswitch
statements. - Indent of tabs with
SwitchCase
set to2
will indentcase
clauses with 2 tabs with respect toswitch
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/
Expected indentation of 10 space characters but found 8. Open
case 'MUT_CNT_VS_CNA':
- Read upRead up
- Exclude checks
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 forcase
clauses inswitch
statements -
"VariableDeclarator"
(default: 1) enforces indentation level forvar
declarators; can also take an object to define separate rules forvar
,let
andconst
declarations.
Level of indentation denotes the multiple of the indent specified. Example:
- Indent of 4 spaces with
VariableDeclarator
set to2
will indent the multi-line variable declarations with 8 spaces. - Indent of 2 spaces with
VariableDeclarator
set to2
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 forvar
andlet
, 6 spaces forconst
statements. - Indent of tab with
VariableDeclarator
set to2
will indent the multi-line variable declarations with 2 tabs. - Indent of 2 spaces with
SwitchCase
set to0
will not indentcase
clauses with respect toswitch
statements. - Indent of 2 spaces with
SwitchCase
set to2
will indentcase
clauses with 4 spaces with respect toswitch
statements. - Indent of tabs with
SwitchCase
set to2
will indentcase
clauses with 2 tabs with respect toswitch
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/
Expected indentation of 12 space characters but found 10. Open
var _dfsStatus = getPriority('DFS_STATUS');
- Read upRead up
- Exclude checks
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 forcase
clauses inswitch
statements -
"VariableDeclarator"
(default: 1) enforces indentation level forvar
declarators; can also take an object to define separate rules forvar
,let
andconst
declarations.
Level of indentation denotes the multiple of the indent specified. Example:
- Indent of 4 spaces with
VariableDeclarator
set to2
will indent the multi-line variable declarations with 8 spaces. - Indent of 2 spaces with
VariableDeclarator
set to2
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 forvar
andlet
, 6 spaces forconst
statements. - Indent of tab with
VariableDeclarator
set to2
will indent the multi-line variable declarations with 2 tabs. - Indent of 2 spaces with
SwitchCase
set to0
will not indentcase
clauses with respect toswitch
statements. - Indent of 2 spaces with
SwitchCase
set to2
will indentcase
clauses with 4 spaces with respect toswitch
statements. - Indent of tabs with
SwitchCase
set to2
will indentcase
clauses with 2 tabs with respect toswitch
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/
Trailing spaces not allowed. Open
* Please see Study-View.md under cBioPortal repository for more information
- Read upRead up
- Exclude checks
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/
Expected indentation of 12 space characters but found 10. Open
if (_dfsStatus === 0 || _dfsMonths === 0) {
- Read upRead up
- Exclude checks
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 forcase
clauses inswitch
statements -
"VariableDeclarator"
(default: 1) enforces indentation level forvar
declarators; can also take an object to define separate rules forvar
,let
andconst
declarations.
Level of indentation denotes the multiple of the indent specified. Example:
- Indent of 4 spaces with
VariableDeclarator
set to2
will indent the multi-line variable declarations with 8 spaces. - Indent of 2 spaces with
VariableDeclarator
set to2
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 forvar
andlet
, 6 spaces forconst
statements. - Indent of tab with
VariableDeclarator
set to2
will indent the multi-line variable declarations with 2 tabs. - Indent of 2 spaces with
SwitchCase
set to0
will not indentcase
clauses with respect toswitch
statements. - Indent of 2 spaces with
SwitchCase
set to2
will indentcase
clauses with 4 spaces with respect toswitch
statements. - Indent of tabs with
SwitchCase
set to2
will indentcase
clauses with 2 tabs with respect toswitch
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/
Expected indentation of 12 space characters but found 10. Open
if (_osStatus === 0 || _osMonths === 0) {
- Read upRead up
- Exclude checks
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 forcase
clauses inswitch
statements -
"VariableDeclarator"
(default: 1) enforces indentation level forvar
declarators; can also take an object to define separate rules forvar
,let
andconst
declarations.
Level of indentation denotes the multiple of the indent specified. Example:
- Indent of 4 spaces with
VariableDeclarator
set to2
will indent the multi-line variable declarations with 8 spaces. - Indent of 2 spaces with
VariableDeclarator
set to2
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 forvar
andlet
, 6 spaces forconst
statements. - Indent of tab with
VariableDeclarator
set to2
will indent the multi-line variable declarations with 2 tabs. - Indent of 2 spaces with
SwitchCase
set to0
will not indentcase
clauses with respect toswitch
statements. - Indent of 2 spaces with
SwitchCase
set to2
will indentcase
clauses with 4 spaces with respect toswitch
statements. - Indent of tabs with
SwitchCase
set to2
will indentcase
clauses with 2 tabs with respect toswitch
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/
Newline required at end of file but not found. Open
window._);
- Read upRead up
- Exclude checks
Require file to end with single newline (eol-last)
(fixable) The --fix
option on the [command line](../user-guide/command-line-interface#fix) automatically fixes problems reported by this rule.
Trailing newlines in non-empty files are a common UNIX idiom. Benefits of trailing newlines include the ability to concatenate or append to files as well as output files to the terminal without interfering with shell prompts.
Rule Details
This rule requires at least one newline at the end of non-empty files.
Prior to v0.16.0 this rule also enforced that there was only a single line at
the end of the file. If you still want this behaviour, consider enabling
[no-multiple-empty-lines](no-multiple-empty-lines.md) with maxEOF
and/or
[no-trailing-spaces](no-trailing-spaces.md).
Examples of incorrect code for this rule:
/*eslint eol-last: "error"*/
function doSmth() {
var foo = 2;
}
Examples of correct code for this rule:
/*eslint eol-last: "error"*/
function doSmth() {
var foo = 2;
}
Options
This rule has a string option:
-
"unix"
(default) enforces line feed (LF) as newline -
"windows"
enforces carriage return line feed (CRLF) as newline Source: http://eslint.org/docs/rules/
Expected indentation of 10 space characters but found 8. Open
case 'DFS_SURVIVAL':
- Read upRead up
- Exclude checks
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 forcase
clauses inswitch
statements -
"VariableDeclarator"
(default: 1) enforces indentation level forvar
declarators; can also take an object to define separate rules forvar
,let
andconst
declarations.
Level of indentation denotes the multiple of the indent specified. Example:
- Indent of 4 spaces with
VariableDeclarator
set to2
will indent the multi-line variable declarations with 8 spaces. - Indent of 2 spaces with
VariableDeclarator
set to2
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 forvar
andlet
, 6 spaces forconst
statements. - Indent of tab with
VariableDeclarator
set to2
will indent the multi-line variable declarations with 2 tabs. - Indent of 2 spaces with
SwitchCase
set to0
will not indentcase
clauses with respect toswitch
statements. - Indent of 2 spaces with
SwitchCase
set to2
will indentcase
clauses with 4 spaces with respect toswitch
statements. - Indent of tabs with
SwitchCase
set to2
will indentcase
clauses with 2 tabs with respect toswitch
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/