Showing 1,297 of 1,297 total issues
Expected an assignment or function call and instead saw an expression. Open
ghost_result = void 0, balloon_result = void 0;
- Read upRead up
- Exclude checks
Disallow Unused Expressions (no-unused-expressions)
An unused expression which has no effect on the state of the program indicates a logic error.
For example, n + 1;
is not a syntax error, but it might be a typing mistake where a programmer meant an assignment statement n += 1;
instead.
Rule Details
This rule aims to eliminate unused expressions which have no effect on the state of the program.
This rule does not apply to function calls or constructor calls with the new
operator, because they could have side effects on the state of the program.
var i = 0;
function increment() { i += 1; }
increment(); // return value is unused, but i changed as a side effect
var nThings = 0;
function Thing() { nThings += 1; }
new Thing(); // constructed object is unused, but nThings changed as a side effect
This rule does not apply to directives (which are in the form of literal string expressions such as "use strict";
at the beginning of a script, module, or function).
Sequence expressions (those using a comma, such as a = 1, b = 2
) are always considered unused unless their return value is assigned or used in a condition evaluation, or a function call is made with the sequence expression value.
Options
This rule, in its default state, does not require any arguments. If you would like to enable one or more of the following you may pass an object with the options set as follows:
-
allowShortCircuit
set totrue
will allow you to use short circuit evaluations in your expressions (Default:false
). -
allowTernary
set totrue
will enable you to use ternary operators in your expressions similarly to short circuit evaluations (Default:false
). -
allowTaggedTemplates
set totrue
will enable you to use tagged template literals in your expressions (Default:false
).
These options allow unused expressions only if all of the code paths either directly change the state (for example, assignment statement) or could have side effects (for example, function call).
Examples of incorrect code for the default { "allowShortCircuit": false, "allowTernary": false }
options:
/*eslint no-unused-expressions: "error"*/
0
if(0) 0
{0}
f(0), {}
a && b()
a, b()
c = a, b;
a() && function namedFunctionInExpressionContext () {f();}
(function anIncompleteIIFE () {});
injectGlobal`body{ color: red; }`
Note that one or more string expression statements (with or without semi-colons) will only be considered as unused if they are not in the beginning of a script, module, or function (alone and uninterrupted by other statements). Otherwise, they will be treated as part of a "directive prologue", a section potentially usable by JavaScript engines. This includes "strict mode" directives.
"use strict";
"use asm"
"use stricter";
"use babel"
"any other strings like this in the prologue";
Examples of correct code for the default { "allowShortCircuit": false, "allowTernary": false }
options:
/*eslint no-unused-expressions: "error"*/
{} // In this context, this is a block statement, not an object literal
{myLabel: someVar} // In this context, this is a block statement with a label and expression, not an object literal
function namedFunctionDeclaration () {}
(function aGenuineIIFE () {}());
f()
a = 0
new C
delete a.b
void a
allowShortCircuit
Examples of incorrect code for the { "allowShortCircuit": true }
option:
/*eslint no-unused-expressions: ["error", { "allowShortCircuit": true }]*/
a || b
Examples of correct code for the { "allowShortCircuit": true }
option:
/*eslint no-unused-expressions: ["error", { "allowShortCircuit": true }]*/
a && b()
a() || (b = c)
allowTernary
Examples of incorrect code for the { "allowTernary": true }
option:
/*eslint no-unused-expressions: ["error", { "allowTernary": true }]*/
a ? b : 0
a ? b : c()
Examples of correct code for the { "allowTernary": true }
option:
/*eslint no-unused-expressions: ["error", { "allowTernary": true }]*/
a ? b() : c()
a ? (b = c) : d()
allowShortCircuit and allowTernary
Examples of correct code for the { "allowShortCircuit": true, "allowTernary": true }
options:
/*eslint no-unused-expressions: ["error", { "allowShortCircuit": true, "allowTernary": true }]*/
a ? b() || (c = d) : e()
allowTaggedTemplates
Examples of incorrect code for the { "allowTaggedTemplates": true }
option:
/*eslint no-unused-expressions: ["error", { "allowTaggedTemplates": true }]*/
`some untagged template string`;
Examples of correct code for the { "allowTaggedTemplates": true }
option:
/*eslint no-unused-expressions: ["error", { "allowTaggedTemplates": true }]*/
tag`some tagged template string`;
Source: http://eslint.org/docs/rules/
Unexpected use of comma operator. Open
ghost_result = void 0, balloon_result = void 0;
- Read upRead up
- Exclude checks
Disallow Use of the Comma Operator (no-sequences)
The comma operator includes multiple expressions where only one is expected. It evaluates each operand from left to right and returns the value of the last operand. However, this frequently obscures side effects, and its use is often an accident. Here are some examples of sequences:
var a = (3, 5); // a = 5
a = b += 5, a + b;
while (a = next(), a && a.length);
(0, eval)("doSomething();");
Rule Details
This rule forbids the use of the comma operator, with the following exceptions:
- In the initialization or update portions of a
for
statement. - If the expression sequence is explicitly wrapped in parentheses.
Examples of incorrect code for this rule:
/*eslint no-sequences: "error"*/
foo = doSomething(), val;
0, eval("doSomething();");
do {} while (doSomething(), !!test);
for (; doSomething(), !!test; );
if (doSomething(), !!test);
switch (val = foo(), val) {}
while (val = foo(), val < 42);
with (doSomething(), val) {}
Examples of correct code for this rule:
/*eslint no-sequences: "error"*/
foo = (doSomething(), val);
(0, eval)("doSomething();");
do {} while ((doSomething(), !!test));
for (i = 0, j = 10; i < j; i++, j--);
if ((doSomething(), !!test));
switch ((val = foo(), val)) {}
while ((val = foo(), val < 42));
// with ((doSomething(), val)) {}
When Not To Use It
Disable this rule if sequence expressions with the comma operator are acceptable. Source: http://eslint.org/docs/rules/
Expected 'undefined' and instead saw 'void'. Open
ghost_result = void 0, balloon_result = void 0;
- Read upRead up
- Exclude checks
Disallow use of the void operator. (no-void)
The void
operator takes an operand and returns undefined
: void expression
will evaluate expression
and return undefined
. It can be used to ignore any side effects expression
may produce:
The common case of using void
operator is to get a "pure" undefined
value as prior to ES5 the undefined
variable was mutable:
// will always return undefined
(function(){
return void 0;
})();
// will return 1 in ES3 and undefined in ES5+
(function(){
undefined = 1;
return undefined;
})();
// will throw TypeError in ES5+
(function(){
'use strict';
undefined = 1;
})();
Another common case is to minify code as void 0
is shorter than undefined
:
foo = void 0;
foo = undefined;
When used with IIFE (immediately-invoked function expression), void
can be used to force the function keyword to be treated as an expression instead of a declaration:
var foo = 1;
void function(){ foo = 1; }() // will assign foo a value of 1
+function(){ foo = 1; }() // same as above
function(){ foo = 1; }() // will throw SyntaxError
Some code styles prohibit void
operator, marking it as non-obvious and hard to read.
Rule Details
This rule aims to eliminate use of void operator.
Examples of incorrect code for this rule:
/*eslint no-void: "error"*/
void foo
var foo = void bar();
When Not To Use It
If you intentionally use the void
operator then you can disable this rule.
Further Reading
Related Rules
- [no-undef-init](no-undef-init.md)
- [no-undefined](no-undefined.md) Source: http://eslint.org/docs/rules/
Bad line breaking before and after ','. Open
,
- Read upRead up
- Exclude checks
Comma style (comma-style)
The Comma Style rule enforces styles for comma-separated lists. There are two comma styles primarily used in JavaScript:
- The standard style, in which commas are placed at the end of the current line
- Comma First style, in which commas are placed at the start of the next line
One of the justifications for using Comma First style is that it can help track missing and trailing commas. These are problematic because missing commas in variable declarations can lead to the leakage of global variables and trailing commas can lead to errors in older versions of IE.
Rule Details
This rule enforce consistent comma style in array literals, object literals, and variable declarations.
This rule does not apply in either of the following cases:
- comma preceded and followed by linebreak (lone comma)
- single-line array literals, object literals, and variable declarations
Options
This rule has a string option:
-
"last"
(default) requires a comma after and on the same line as an array element, object property, or variable declaration -
"first"
requires a comma before and on the same line as an array element, object property, or variable declaration
This rule also accepts an additional exceptions
object:
-
"exceptions"
has properties whose names correspond to node types in the abstract syntax tree (AST) of JavaScript code:-
"ArrayExpression": true
ignores comma style in array literals -
"ArrayPattern": true
ignores comma style in array patterns of destructuring -
"ArrowFunctionExpression": true
ignores comma style in the parameters of arrow function expressions -
"CallExpression": true
ignores comma style in the arguments of function calls -
"FunctionDeclaration": true
ignores comma style in the parameters of function declarations -
"FunctionExpression": true
ignores comma style in the parameters of function expressions -
"ImportDeclaration": true
ignores comma style in the specifiers of import declarations -
"ObjectExpression": true
ignores comma style in object literals -
"ObjectPattern": true
ignores comma style in object patterns of destructuring -
"VariableDeclaration": true
ignores comma style in variable declarations
-
A way to determine the node types as defined by ESTree is to use the online demo.
last
Examples of incorrect code for this rule with the default "last"
option:
/*eslint comma-style: ["error", "last"]*/
var foo = 1
,
bar = 2;
var foo = 1
, bar = 2;
var foo = ["apples"
, "oranges"];
function bar() {
return {
"a": 1
,"b:": 2
};
}
Examples of correct code for this rule with the default "last"
option:
/*eslint comma-style: ["error", "last"]*/
var foo = 1, bar = 2;
var foo = 1,
bar = 2;
var foo = ["apples",
"oranges"];
function bar() {
return {
"a": 1,
"b:": 2
};
}
first
Examples of incorrect code for this rule with the "first"
option:
/*eslint comma-style: ["error", "first"]*/
var foo = 1,
bar = 2;
var foo = ["apples",
"oranges"];
function bar() {
return {
"a": 1,
"b:": 2
};
}
Examples of correct code for this rule with the "first"
option:
/*eslint comma-style: ["error", "first"]*/
var foo = 1, bar = 2;
var foo = 1
,bar = 2;
var foo = ["apples"
,"oranges"];
function bar() {
return {
"a": 1
,"b:": 2
};
}
exceptions
An example use case is to enforce comma style only in var statements.
Examples of incorrect code for this rule with sample "first", { "exceptions": { … } }
options:
/*eslint comma-style: ["error", "first", { "exceptions": { "ArrayExpression": true, "ObjectExpression": true } }]*/
var o = {},
a = [];
Examples of correct code for this rule with sample "first", { "exceptions": { … } }
options:
/*eslint comma-style: ["error", "first", { "exceptions": { "ArrayExpression": true, "ObjectExpression": true } }]*/
var o = {fst:1,
snd: [1,
2]}
, a = [];
When Not To Use It
This rule can safely be turned off if your project does not care about enforcing a consistent comma style.
Further Reading
For more information on the Comma First style:
- A better coding convention for lists and object literals in JavaScript by isaacs
- npm coding style guideline
Related Rules
- [operator-linebreak](operator-linebreak.md) Source: http://eslint.org/docs/rules/
Expected linebreaks to be 'LF' but found 'CRLF'. Open
* デフォルトのゴーストのビュークラス
- Read upRead up
- Exclude checks
enforce consistent linebreak style (linebreak-style)
When developing with a lot of people all having different editors, VCS applications and operating systems it may occur that different line endings are written by either of the mentioned (might especially happen when using the windows and mac versions of SourceTree together).
The linebreaks (new lines) used in windows operating system are usually carriage returns (CR) followed by a line feed (LF) making it a carriage return line feed (CRLF)
whereas Linux and Unix use a simple line feed (LF). The corresponding control sequences are "\n"
(for LF) and "\r\n"
for (CRLF).
Many versioning systems (like git and subversion) can automatically ensure the correct ending. However to cover all contingencies, you can activate this rule.
Rule Details
This rule enforces consistent line endings independent of operating system, VCS, or editor used across your codebase.
Options
This rule has a string option:
-
"unix"
(default) enforces the usage of Unix line endings:\n
for LF. -
"windows"
enforces the usage of Windows line endings:\r\n
for CRLF.
unix
Examples of incorrect code for this rule with the default "unix"
option:
/*eslint linebreak-style: ["error", "unix"]*/
var a = 'a'; // \r\n
Examples of correct code for this rule with the default "unix"
option:
/*eslint linebreak-style: ["error", "unix"]*/
var a = 'a', // \n
b = 'b'; // \n
// \n
function foo(params) { // \n
// do stuff \n
}// \n
windows
Examples of incorrect code for this rule with the "windows"
option:
/*eslint linebreak-style: ["error", "windows"]*/
var a = 'a'; // \n
Examples of correct code for this rule with the "windows"
option:
/*eslint linebreak-style: ["error", "windows"]*/
var a = 'a', // \r\n
b = 'b'; // \r\n
// \r\n
function foo(params) { // \r\n
// do stuff \r\n
} // \r\n
Using this rule with version control systems
Version control systems sometimes have special behavior for linebreaks. To make it easy for developers to contribute to your codebase from different platforms, you may want to configure your VCS to handle linebreaks appropriately.
For example, the default behavior of git on Windows systems is to convert LF linebreaks to CRLF when checking out files, but to store the linebreaks as LF when committing a change. This will cause the linebreak-style
rule to report errors if configured with the "unix"
setting, because the files that ESLint sees will have CRLF linebreaks. If you use git, you may want to add a line to your .gitattributes
file to prevent git from converting linebreaks in .js
files:
*.js text eol=lf
When Not To Use It
If you aren't concerned about having different line endings within your code, then you can safely turn this rule off.
Compatibility
- JSCS: validateLineBreaks Source: http://eslint.org/docs/rules/
Expected linebreaks to be 'LF' but found 'CRLF'. Open
/**
- Read upRead up
- Exclude checks
enforce consistent linebreak style (linebreak-style)
When developing with a lot of people all having different editors, VCS applications and operating systems it may occur that different line endings are written by either of the mentioned (might especially happen when using the windows and mac versions of SourceTree together).
The linebreaks (new lines) used in windows operating system are usually carriage returns (CR) followed by a line feed (LF) making it a carriage return line feed (CRLF)
whereas Linux and Unix use a simple line feed (LF). The corresponding control sequences are "\n"
(for LF) and "\r\n"
for (CRLF).
Many versioning systems (like git and subversion) can automatically ensure the correct ending. However to cover all contingencies, you can activate this rule.
Rule Details
This rule enforces consistent line endings independent of operating system, VCS, or editor used across your codebase.
Options
This rule has a string option:
-
"unix"
(default) enforces the usage of Unix line endings:\n
for LF. -
"windows"
enforces the usage of Windows line endings:\r\n
for CRLF.
unix
Examples of incorrect code for this rule with the default "unix"
option:
/*eslint linebreak-style: ["error", "unix"]*/
var a = 'a'; // \r\n
Examples of correct code for this rule with the default "unix"
option:
/*eslint linebreak-style: ["error", "unix"]*/
var a = 'a', // \n
b = 'b'; // \n
// \n
function foo(params) { // \n
// do stuff \n
}// \n
windows
Examples of incorrect code for this rule with the "windows"
option:
/*eslint linebreak-style: ["error", "windows"]*/
var a = 'a'; // \n
Examples of correct code for this rule with the "windows"
option:
/*eslint linebreak-style: ["error", "windows"]*/
var a = 'a', // \r\n
b = 'b'; // \r\n
// \r\n
function foo(params) { // \r\n
// do stuff \r\n
} // \r\n
Using this rule with version control systems
Version control systems sometimes have special behavior for linebreaks. To make it easy for developers to contribute to your codebase from different platforms, you may want to configure your VCS to handle linebreaks appropriately.
For example, the default behavior of git on Windows systems is to convert LF linebreaks to CRLF when checking out files, but to store the linebreaks as LF when committing a change. This will cause the linebreak-style
rule to report errors if configured with the "unix"
setting, because the files that ESLint sees will have CRLF linebreaks. If you use git, you may want to add a line to your .gitattributes
file to prevent git from converting linebreaks in .js
files:
*.js text eol=lf
When Not To Use It
If you aren't concerned about having different line endings within your code, then you can safely turn this rule off.
Compatibility
- JSCS: validateLineBreaks Source: http://eslint.org/docs/rules/
Expected linebreaks to be 'LF' but found 'CRLF'. Open
* @type {cuttlebone}
- Read upRead up
- Exclude checks
enforce consistent linebreak style (linebreak-style)
When developing with a lot of people all having different editors, VCS applications and operating systems it may occur that different line endings are written by either of the mentioned (might especially happen when using the windows and mac versions of SourceTree together).
The linebreaks (new lines) used in windows operating system are usually carriage returns (CR) followed by a line feed (LF) making it a carriage return line feed (CRLF)
whereas Linux and Unix use a simple line feed (LF). The corresponding control sequences are "\n"
(for LF) and "\r\n"
for (CRLF).
Many versioning systems (like git and subversion) can automatically ensure the correct ending. However to cover all contingencies, you can activate this rule.
Rule Details
This rule enforces consistent line endings independent of operating system, VCS, or editor used across your codebase.
Options
This rule has a string option:
-
"unix"
(default) enforces the usage of Unix line endings:\n
for LF. -
"windows"
enforces the usage of Windows line endings:\r\n
for CRLF.
unix
Examples of incorrect code for this rule with the default "unix"
option:
/*eslint linebreak-style: ["error", "unix"]*/
var a = 'a'; // \r\n
Examples of correct code for this rule with the default "unix"
option:
/*eslint linebreak-style: ["error", "unix"]*/
var a = 'a', // \n
b = 'b'; // \n
// \n
function foo(params) { // \n
// do stuff \n
}// \n
windows
Examples of incorrect code for this rule with the "windows"
option:
/*eslint linebreak-style: ["error", "windows"]*/
var a = 'a'; // \n
Examples of correct code for this rule with the "windows"
option:
/*eslint linebreak-style: ["error", "windows"]*/
var a = 'a', // \r\n
b = 'b'; // \r\n
// \r\n
function foo(params) { // \r\n
// do stuff \r\n
} // \r\n
Using this rule with version control systems
Version control systems sometimes have special behavior for linebreaks. To make it easy for developers to contribute to your codebase from different platforms, you may want to configure your VCS to handle linebreaks appropriately.
For example, the default behavior of git on Windows systems is to convert LF linebreaks to CRLF when checking out files, but to store the linebreaks as LF when committing a change. This will cause the linebreak-style
rule to report errors if configured with the "unix"
setting, because the files that ESLint sees will have CRLF linebreaks. If you use git, you may want to add a line to your .gitattributes
file to prevent git from converting linebreaks in .js
files:
*.js text eol=lf
When Not To Use It
If you aren't concerned about having different line endings within your code, then you can safely turn this rule off.
Compatibility
- JSCS: validateLineBreaks Source: http://eslint.org/docs/rules/
Expected a default case. Open
switch (_context10.prev = _context10.next) {
- 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. The comment may be in any desired case, such as // No Default
.
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
}
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$/i
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/
No magic number: 3. Open
case 3:
- Read upRead up
- Exclude checks
Disallow Magic Numbers (no-magic-numbers)
'Magic numbers' are numbers that occur multiple time in code without an explicit meaning. They should preferably be replaced by named constants.
var now = Date.now(),
inOneHour = now + (60 * 60 * 1000);
Rule Details
The no-magic-numbers
rule aims to make code more readable and refactoring easier by ensuring that special numbers
are declared as constants to make their meaning explicit.
Examples of incorrect code for this rule:
/*eslint no-magic-numbers: "error"*/
var dutyFreePrice = 100,
finalPrice = dutyFreePrice + (dutyFreePrice * 0.25);
/*eslint no-magic-numbers: "error"*/
var data = ['foo', 'bar', 'baz'];
var dataLast = data[2];
/*eslint no-magic-numbers: "error"*/
var SECONDS;
SECONDS = 60;
Examples of correct code for this rule:
/*eslint no-magic-numbers: "error"*/
var TAX = 0.25;
var dutyFreePrice = 100,
finalPrice = dutyFreePrice + (dutyFreePrice * TAX);
Options
ignore
An array of numbers to ignore. It's set to []
by default.
If provided, it must be an Array
.
Examples of correct code for the sample { "ignore": [1] }
option:
/*eslint no-magic-numbers: ["error", { "ignore": [1] }]*/
var data = ['foo', 'bar', 'baz'];
var dataLast = data.length && data[data.length - 1];
ignoreArrayIndexes
A boolean to specify if numbers used as array indexes are considered okay. false
by default.
Examples of correct code for the { "ignoreArrayIndexes": true }
option:
/*eslint no-magic-numbers: ["error", { "ignoreArrayIndexes": true }]*/
var data = ['foo', 'bar', 'baz'];
var dataLast = data[2];
enforceConst
A boolean to specify if we should check for the const keyword in variable declaration of numbers. false
by default.
Examples of incorrect code for the { "enforceConst": true }
option:
/*eslint no-magic-numbers: ["error", { "enforceConst": true }]*/
var TAX = 0.25;
var dutyFreePrice = 100,
finalPrice = dutyFreePrice + (dutyFreePrice * TAX);
detectObjects
A boolean to specify if we should detect numbers when setting object properties for example. false
by default.
Examples of incorrect code for the { "detectObjects": true }
option:
/*eslint no-magic-numbers: ["error", { "detectObjects": true }]*/
var magic = {
tax: 0.25
};
var dutyFreePrice = 100,
finalPrice = dutyFreePrice + (dutyFreePrice * magic.tax);
Examples of correct code for the { "detectObjects": true }
option:
/*eslint no-magic-numbers: ["error", { "detectObjects": true }]*/
var TAX = 0.25;
var magic = {
tax: TAX
};
var dutyFreePrice = 100,
finalPrice = dutyFreePrice + (dutyFreePrice * magic.tax);
Source: http://eslint.org/docs/rules/
Assignment to property of function parameter '_context11'. Open
_context11.next = 10;
- Read upRead up
- Exclude checks
Disallow Reassignment of Function Parameters (no-param-reassign)
Assignment to variables declared as function parameters can be misleading and lead to confusing behavior, as modifying function parameters will also mutate the arguments
object. Often, assignment to function parameters is unintended and indicative of a mistake or programmer error.
This rule can be also configured to fail when function parameters are modified. Side effects on parameters can cause counter-intuitive execution flow and make errors difficult to track down.
Rule Details
This rule aims to prevent unintended behavior caused by modification or reassignment of function parameters.
Examples of incorrect code for this rule:
/*eslint no-param-reassign: "error"*/
function foo(bar) {
bar = 13;
}
function foo(bar) {
bar++;
}
Examples of correct code for this rule:
/*eslint no-param-reassign: "error"*/
function foo(bar) {
var baz = bar;
}
Options
This rule takes one option, an object, with a boolean property "props"
and an array "ignorePropertyModificationsFor"
. "props"
is false
by default. If "props"
is set to true
, this rule warns against the modification of parameter properties unless they're included in "ignorePropertyModificationsFor"
, which is an empty array by default.
props
Examples of correct code for the default { "props": false }
option:
/*eslint no-param-reassign: ["error", { "props": false }]*/
function foo(bar) {
bar.prop = "value";
}
function foo(bar) {
delete bar.aaa;
}
function foo(bar) {
bar.aaa++;
}
Examples of incorrect code for the { "props": true }
option:
/*eslint no-param-reassign: ["error", { "props": true }]*/
function foo(bar) {
bar.prop = "value";
}
function foo(bar) {
delete bar.aaa;
}
function foo(bar) {
bar.aaa++;
}
Examples of correct code for the { "props": true }
option with "ignorePropertyModificationsFor"
set:
/*eslint no-param-reassign: ["error", { "props": true, "ignorePropertyModificationsFor": ["bar"] }]*/
function foo(bar) {
bar.prop = "value";
}
function foo(bar) {
delete bar.aaa;
}
function foo(bar) {
bar.aaa++;
}
When Not To Use It
If you want to allow assignment to function parameters, then you can safely disable this rule.
Further Reading
No magic number: 16. Open
case 16:
- Read upRead up
- Exclude checks
Disallow Magic Numbers (no-magic-numbers)
'Magic numbers' are numbers that occur multiple time in code without an explicit meaning. They should preferably be replaced by named constants.
var now = Date.now(),
inOneHour = now + (60 * 60 * 1000);
Rule Details
The no-magic-numbers
rule aims to make code more readable and refactoring easier by ensuring that special numbers
are declared as constants to make their meaning explicit.
Examples of incorrect code for this rule:
/*eslint no-magic-numbers: "error"*/
var dutyFreePrice = 100,
finalPrice = dutyFreePrice + (dutyFreePrice * 0.25);
/*eslint no-magic-numbers: "error"*/
var data = ['foo', 'bar', 'baz'];
var dataLast = data[2];
/*eslint no-magic-numbers: "error"*/
var SECONDS;
SECONDS = 60;
Examples of correct code for this rule:
/*eslint no-magic-numbers: "error"*/
var TAX = 0.25;
var dutyFreePrice = 100,
finalPrice = dutyFreePrice + (dutyFreePrice * TAX);
Options
ignore
An array of numbers to ignore. It's set to []
by default.
If provided, it must be an Array
.
Examples of correct code for the sample { "ignore": [1] }
option:
/*eslint no-magic-numbers: ["error", { "ignore": [1] }]*/
var data = ['foo', 'bar', 'baz'];
var dataLast = data.length && data[data.length - 1];
ignoreArrayIndexes
A boolean to specify if numbers used as array indexes are considered okay. false
by default.
Examples of correct code for the { "ignoreArrayIndexes": true }
option:
/*eslint no-magic-numbers: ["error", { "ignoreArrayIndexes": true }]*/
var data = ['foo', 'bar', 'baz'];
var dataLast = data[2];
enforceConst
A boolean to specify if we should check for the const keyword in variable declaration of numbers. false
by default.
Examples of incorrect code for the { "enforceConst": true }
option:
/*eslint no-magic-numbers: ["error", { "enforceConst": true }]*/
var TAX = 0.25;
var dutyFreePrice = 100,
finalPrice = dutyFreePrice + (dutyFreePrice * TAX);
detectObjects
A boolean to specify if we should detect numbers when setting object properties for example. false
by default.
Examples of incorrect code for the { "detectObjects": true }
option:
/*eslint no-magic-numbers: ["error", { "detectObjects": true }]*/
var magic = {
tax: 0.25
};
var dutyFreePrice = 100,
finalPrice = dutyFreePrice + (dutyFreePrice * magic.tax);
Examples of correct code for the { "detectObjects": true }
option:
/*eslint no-magic-numbers: ["error", { "detectObjects": true }]*/
var TAX = 0.25;
var magic = {
tax: TAX
};
var dutyFreePrice = 100,
finalPrice = dutyFreePrice + (dutyFreePrice * magic.tax);
Source: http://eslint.org/docs/rules/
Unexpected 'this'. Open
this.emit('install_nar_loaded', target, nar);
- Read upRead up
- Exclude checks
Disallow this
keywords outside of classes or class-like objects. (no-invalid-this)
Under the strict mode, this
keywords outside of classes or class-like objects might be undefined
and raise a TypeError
.
Rule Details
This rule aims to flag usage of this
keywords outside of classes or class-like objects.
Basically this rule checks whether or not a function which are containing this
keywords is a constructor or a method.
This rule judges from following conditions whether or not the function is a constructor:
- The name of the function starts with uppercase.
- The function is assigned to a variable which starts with an uppercase letter.
- The function is a constructor of ES2015 Classes.
This rule judges from following conditions whether or not the function is a method:
- The function is on an object literal.
- The function is assigned to a property.
- The function is a method/getter/setter of ES2015 Classes. (excepts static methods)
And this rule allows this
keywords in functions below:
- The
call/apply/bind
method of the function is called directly. - The function is a callback of array methods (such as
.forEach()
) ifthisArg
is given. - The function has
@this
tag in its JSDoc comment.
Otherwise are considered problems.
This rule applies only in strict mode.
With "parserOptions": { "sourceType": "module" }
in the ESLint configuration, your code is in strict mode even without a "use strict"
directive.
Examples of incorrect code for this rule in strict mode:
/*eslint no-invalid-this: "error"*/
/*eslint-env es6*/
"use strict";
this.a = 0;
baz(() => this);
(function() {
this.a = 0;
baz(() => this);
})();
function foo() {
this.a = 0;
baz(() => this);
}
var foo = function() {
this.a = 0;
baz(() => this);
};
foo(function() {
this.a = 0;
baz(() => this);
});
obj.foo = () => {
// `this` of arrow functions is the outer scope's.
this.a = 0;
};
var obj = {
aaa: function() {
return function foo() {
// There is in a method `aaa`, but `foo` is not a method.
this.a = 0;
baz(() => this);
};
}
};
foo.forEach(function() {
this.a = 0;
baz(() => this);
});
Examples of correct code for this rule in strict mode:
/*eslint no-invalid-this: "error"*/
/*eslint-env es6*/
"use strict";
function Foo() {
// OK, this is in a legacy style constructor.
this.a = 0;
baz(() => this);
}
class Foo {
constructor() {
// OK, this is in a constructor.
this.a = 0;
baz(() => this);
}
}
var obj = {
foo: function foo() {
// OK, this is in a method (this function is on object literal).
this.a = 0;
}
};
var obj = {
foo() {
// OK, this is in a method (this function is on object literal).
this.a = 0;
}
};
var obj = {
get foo() {
// OK, this is in a method (this function is on object literal).
return this.a;
}
};
var obj = Object.create(null, {
foo: {value: function foo() {
// OK, this is in a method (this function is on object literal).
this.a = 0;
}}
});
Object.defineProperty(obj, "foo", {
value: function foo() {
// OK, this is in a method (this function is on object literal).
this.a = 0;
}
});
Object.defineProperties(obj, {
foo: {value: function foo() {
// OK, this is in a method (this function is on object literal).
this.a = 0;
}}
});
function Foo() {
this.foo = function foo() {
// OK, this is in a method (this function assigns to a property).
this.a = 0;
baz(() => this);
};
}
obj.foo = function foo() {
// OK, this is in a method (this function assigns to a property).
this.a = 0;
};
Foo.prototype.foo = function foo() {
// OK, this is in a method (this function assigns to a property).
this.a = 0;
};
class Foo {
foo() {
// OK, this is in a method.
this.a = 0;
baz(() => this);
}
static foo() {
// OK, this is in a method (static methods also have valid this).
this.a = 0;
baz(() => this);
}
}
var foo = (function foo() {
// OK, the `bind` method of this function is called directly.
this.a = 0;
}).bind(obj);
foo.forEach(function() {
// OK, `thisArg` of `.forEach()` is given.
this.a = 0;
baz(() => this);
}, thisArg);
/** @this Foo */
function foo() {
// OK, this function has a `@this` tag in its JSDoc comment.
this.a = 0;
}
When Not To Use It
If you don't want to be notified about usage of this
keyword outside of classes or class-like objects, you can safely disable this rule.
Source: http://eslint.org/docs/rules/
Unexpected use of comma operator. Open
dirpath = void 0, sakuraname = void 0;
- Read upRead up
- Exclude checks
Disallow Use of the Comma Operator (no-sequences)
The comma operator includes multiple expressions where only one is expected. It evaluates each operand from left to right and returns the value of the last operand. However, this frequently obscures side effects, and its use is often an accident. Here are some examples of sequences:
var a = (3, 5); // a = 5
a = b += 5, a + b;
while (a = next(), a && a.length);
(0, eval)("doSomething();");
Rule Details
This rule forbids the use of the comma operator, with the following exceptions:
- In the initialization or update portions of a
for
statement. - If the expression sequence is explicitly wrapped in parentheses.
Examples of incorrect code for this rule:
/*eslint no-sequences: "error"*/
foo = doSomething(), val;
0, eval("doSomething();");
do {} while (doSomething(), !!test);
for (; doSomething(), !!test; );
if (doSomething(), !!test);
switch (val = foo(), val) {}
while (val = foo(), val < 42);
with (doSomething(), val) {}
Examples of correct code for this rule:
/*eslint no-sequences: "error"*/
foo = (doSomething(), val);
(0, eval)("doSomething();");
do {} while ((doSomething(), !!test));
for (i = 0, j = 10; i < j; i++, j--);
if ((doSomething(), !!test));
switch ((val = foo(), val)) {}
while ((val = foo(), val < 42));
// with ((doSomething(), val)) {}
When Not To Use It
Disable this rule if sequence expressions with the comma operator are acceptable. Source: http://eslint.org/docs/rules/
Unexpected 'this'. Open
dirpath = typeof from === 'string' || from instanceof String ? from : this.namedId(from);
- Read upRead up
- Exclude checks
Disallow this
keywords outside of classes or class-like objects. (no-invalid-this)
Under the strict mode, this
keywords outside of classes or class-like objects might be undefined
and raise a TypeError
.
Rule Details
This rule aims to flag usage of this
keywords outside of classes or class-like objects.
Basically this rule checks whether or not a function which are containing this
keywords is a constructor or a method.
This rule judges from following conditions whether or not the function is a constructor:
- The name of the function starts with uppercase.
- The function is assigned to a variable which starts with an uppercase letter.
- The function is a constructor of ES2015 Classes.
This rule judges from following conditions whether or not the function is a method:
- The function is on an object literal.
- The function is assigned to a property.
- The function is a method/getter/setter of ES2015 Classes. (excepts static methods)
And this rule allows this
keywords in functions below:
- The
call/apply/bind
method of the function is called directly. - The function is a callback of array methods (such as
.forEach()
) ifthisArg
is given. - The function has
@this
tag in its JSDoc comment.
Otherwise are considered problems.
This rule applies only in strict mode.
With "parserOptions": { "sourceType": "module" }
in the ESLint configuration, your code is in strict mode even without a "use strict"
directive.
Examples of incorrect code for this rule in strict mode:
/*eslint no-invalid-this: "error"*/
/*eslint-env es6*/
"use strict";
this.a = 0;
baz(() => this);
(function() {
this.a = 0;
baz(() => this);
})();
function foo() {
this.a = 0;
baz(() => this);
}
var foo = function() {
this.a = 0;
baz(() => this);
};
foo(function() {
this.a = 0;
baz(() => this);
});
obj.foo = () => {
// `this` of arrow functions is the outer scope's.
this.a = 0;
};
var obj = {
aaa: function() {
return function foo() {
// There is in a method `aaa`, but `foo` is not a method.
this.a = 0;
baz(() => this);
};
}
};
foo.forEach(function() {
this.a = 0;
baz(() => this);
});
Examples of correct code for this rule in strict mode:
/*eslint no-invalid-this: "error"*/
/*eslint-env es6*/
"use strict";
function Foo() {
// OK, this is in a legacy style constructor.
this.a = 0;
baz(() => this);
}
class Foo {
constructor() {
// OK, this is in a constructor.
this.a = 0;
baz(() => this);
}
}
var obj = {
foo: function foo() {
// OK, this is in a method (this function is on object literal).
this.a = 0;
}
};
var obj = {
foo() {
// OK, this is in a method (this function is on object literal).
this.a = 0;
}
};
var obj = {
get foo() {
// OK, this is in a method (this function is on object literal).
return this.a;
}
};
var obj = Object.create(null, {
foo: {value: function foo() {
// OK, this is in a method (this function is on object literal).
this.a = 0;
}}
});
Object.defineProperty(obj, "foo", {
value: function foo() {
// OK, this is in a method (this function is on object literal).
this.a = 0;
}
});
Object.defineProperties(obj, {
foo: {value: function foo() {
// OK, this is in a method (this function is on object literal).
this.a = 0;
}}
});
function Foo() {
this.foo = function foo() {
// OK, this is in a method (this function assigns to a property).
this.a = 0;
baz(() => this);
};
}
obj.foo = function foo() {
// OK, this is in a method (this function assigns to a property).
this.a = 0;
};
Foo.prototype.foo = function foo() {
// OK, this is in a method (this function assigns to a property).
this.a = 0;
};
class Foo {
foo() {
// OK, this is in a method.
this.a = 0;
baz(() => this);
}
static foo() {
// OK, this is in a method (static methods also have valid this).
this.a = 0;
baz(() => this);
}
}
var foo = (function foo() {
// OK, the `bind` method of this function is called directly.
this.a = 0;
}).bind(obj);
foo.forEach(function() {
// OK, `thisArg` of `.forEach()` is given.
this.a = 0;
baz(() => this);
}, thisArg);
/** @this Foo */
function foo() {
// OK, this function has a `@this` tag in its JSDoc comment.
this.a = 0;
}
When Not To Use It
If you don't want to be notified about usage of this
keyword outside of classes or class-like objects, you can safely disable this rule.
Source: http://eslint.org/docs/rules/
Expected 'undefined' and instead saw 'void'. Open
ghost_result = void 0, balloon_result = void 0;
- Read upRead up
- Exclude checks
Disallow use of the void operator. (no-void)
The void
operator takes an operand and returns undefined
: void expression
will evaluate expression
and return undefined
. It can be used to ignore any side effects expression
may produce:
The common case of using void
operator is to get a "pure" undefined
value as prior to ES5 the undefined
variable was mutable:
// will always return undefined
(function(){
return void 0;
})();
// will return 1 in ES3 and undefined in ES5+
(function(){
undefined = 1;
return undefined;
})();
// will throw TypeError in ES5+
(function(){
'use strict';
undefined = 1;
})();
Another common case is to minify code as void 0
is shorter than undefined
:
foo = void 0;
foo = undefined;
When used with IIFE (immediately-invoked function expression), void
can be used to force the function keyword to be treated as an expression instead of a declaration:
var foo = 1;
void function(){ foo = 1; }() // will assign foo a value of 1
+function(){ foo = 1; }() // same as above
function(){ foo = 1; }() // will throw SyntaxError
Some code styles prohibit void
operator, marking it as non-obvious and hard to read.
Rule Details
This rule aims to eliminate use of void operator.
Examples of incorrect code for this rule:
/*eslint no-void: "error"*/
void foo
var foo = void bar();
When Not To Use It
If you intentionally use the void
operator then you can disable this rule.
Further Reading
Related Rules
- [no-undef-init](no-undef-init.md)
- [no-undefined](no-undefined.md) Source: http://eslint.org/docs/rules/
Use the rest parameters instead of 'arguments'. Open
var GhostViewClass = arguments.length <= 1 || arguments[1] === undefined ? this.GhostViewClass : arguments[1];
- Read upRead up
- Exclude checks
Suggest using the rest parameters instead of arguments
(prefer-rest-params)
There are rest parameters in ES2015.
We can use that feature for variadic functions instead of the arguments
variable.
arguments
does not have methods of Array.prototype
, so it's a bit of an inconvenience.
Rule Details
This rule is aimed to flag usage of arguments
variables.
Examples
Examples of incorrect code for this rule:
function foo() {
console.log(arguments);
}
function foo(action) {
var args = Array.prototype.slice.call(arguments, 1);
action.apply(null, args);
}
function foo(action) {
var args = [].slice.call(arguments, 1);
action.apply(null, args);
}
Examples of correct code for this rule:
function foo(...args) {
console.log(args);
}
function foo(action, ...args) {
action.apply(null, args); // or `action(...args)`, related to the `prefer-spread` rule.
}
// Note: the implicit arguments can be overwritten.
function foo(arguments) {
console.log(arguments); // This is the first argument.
}
function foo() {
var arguments = 0;
console.log(arguments); // This is a local variable.
}
When Not To Use It
This rule should not be used in ES3/5 environments.
In ES2015 (ES6) or later, if you don't want to be notified about arguments
variables, then it's safe to disable this rule.
Related Rules
- [prefer-spread](prefer-spread.md) Source: http://eslint.org/docs/rules/
Expected linebreaks to be 'LF' but found 'CRLF'. Open
* ゴーストのビュークラス
- Read upRead up
- Exclude checks
enforce consistent linebreak style (linebreak-style)
When developing with a lot of people all having different editors, VCS applications and operating systems it may occur that different line endings are written by either of the mentioned (might especially happen when using the windows and mac versions of SourceTree together).
The linebreaks (new lines) used in windows operating system are usually carriage returns (CR) followed by a line feed (LF) making it a carriage return line feed (CRLF)
whereas Linux and Unix use a simple line feed (LF). The corresponding control sequences are "\n"
(for LF) and "\r\n"
for (CRLF).
Many versioning systems (like git and subversion) can automatically ensure the correct ending. However to cover all contingencies, you can activate this rule.
Rule Details
This rule enforces consistent line endings independent of operating system, VCS, or editor used across your codebase.
Options
This rule has a string option:
-
"unix"
(default) enforces the usage of Unix line endings:\n
for LF. -
"windows"
enforces the usage of Windows line endings:\r\n
for CRLF.
unix
Examples of incorrect code for this rule with the default "unix"
option:
/*eslint linebreak-style: ["error", "unix"]*/
var a = 'a'; // \r\n
Examples of correct code for this rule with the default "unix"
option:
/*eslint linebreak-style: ["error", "unix"]*/
var a = 'a', // \n
b = 'b'; // \n
// \n
function foo(params) { // \n
// do stuff \n
}// \n
windows
Examples of incorrect code for this rule with the "windows"
option:
/*eslint linebreak-style: ["error", "windows"]*/
var a = 'a'; // \n
Examples of correct code for this rule with the "windows"
option:
/*eslint linebreak-style: ["error", "windows"]*/
var a = 'a', // \r\n
b = 'b'; // \r\n
// \r\n
function foo(params) { // \r\n
// do stuff \r\n
} // \r\n
Using this rule with version control systems
Version control systems sometimes have special behavior for linebreaks. To make it easy for developers to contribute to your codebase from different platforms, you may want to configure your VCS to handle linebreaks appropriately.
For example, the default behavior of git on Windows systems is to convert LF linebreaks to CRLF when checking out files, but to store the linebreaks as LF when committing a change. This will cause the linebreak-style
rule to report errors if configured with the "unix"
setting, because the files that ESLint sees will have CRLF linebreaks. If you use git, you may want to add a line to your .gitattributes
file to prevent git from converting linebreaks in .js
files:
*.js text eol=lf
When Not To Use It
If you aren't concerned about having different line endings within your code, then you can safely turn this rule off.
Compatibility
- JSCS: validateLineBreaks Source: http://eslint.org/docs/rules/
Wrap an immediate function invocation in parentheses. Open
value: function () {
- Read upRead up
- Exclude checks
Require IIFEs to be Wrapped (wrap-iife)
You can immediately invoke function expressions, but not function declarations. A common technique to create an immediately-invoked function expression (IIFE) is to wrap a function declaration in parentheses. The opening parentheses causes the contained function to be parsed as an expression, rather than a declaration.
// function expression could be unwrapped
var x = function () { return { y: 1 };}();
// function declaration must be wrapped
function () { /* side effects */ }(); // SyntaxError
Rule Details
This rule requires all immediately-invoked function expressions to be wrapped in parentheses.
Options
This rule has two options, a string option and an object option.
String option:
-
"outside"
enforces always wrapping the call expression. The default is"outside"
. -
"inside"
enforces always wrapping the function expression. -
"any"
enforces always wrapping, but allows either style.
Object option:
-
"functionPrototypeMethods": true
additionally enforces wrapping function expressions invoked using.call
and.apply
. The default isfalse
.
outside
Examples of incorrect code for the default "outside"
option:
/*eslint wrap-iife: ["error", "outside"]*/
var x = function () { return { y: 1 };}(); // unwrapped
var x = (function () { return { y: 1 };})(); // wrapped function expression
Examples of correct code for the default "outside"
option:
/*eslint wrap-iife: ["error", "outside"]*/
var x = (function () { return { y: 1 };}()); // wrapped call expression
inside
Examples of incorrect code for the "inside"
option:
/*eslint wrap-iife: ["error", "inside"]*/
var x = function () { return { y: 1 };}(); // unwrapped
var x = (function () { return { y: 1 };}()); // wrapped call expression
Examples of correct code for the "inside"
option:
/*eslint wrap-iife: ["error", "inside"]*/
var x = (function () { return { y: 1 };})(); // wrapped function expression
any
Examples of incorrect code for the "any"
option:
/*eslint wrap-iife: ["error", "any"]*/
var x = function () { return { y: 1 };}(); // unwrapped
Examples of correct code for the "any"
option:
/*eslint wrap-iife: ["error", "any"]*/
var x = (function () { return { y: 1 };}()); // wrapped call expression
var x = (function () { return { y: 1 };})(); // wrapped function expression
functionPrototypeMethods
Examples of incorrect code for this rule with the "inside", { "functionPrototypeMethods": true }
options:
/* eslint wrap-iife: [2, "inside", { functionPrototypeMethods: true }] */
var x = function(){ foo(); }()
var x = (function(){ foo(); }())
var x = function(){ foo(); }.call(bar)
var x = (function(){ foo(); }.call(bar))
Examples of correct code for this rule with the "inside", { "functionPrototypeMethods": true }
options:
/* eslint wrap-iife: [2, "inside", { functionPrototypeMethods: true }] */
var x = (function(){ foo(); })()
var x = (function(){ foo(); }).call(bar)
Source: http://eslint.org/docs/rules/
No magic number: 0. Open
var _ref13 = (0, _asyncToGenerator3.default)(_regenerator2.default.mark(function _callee11(target) {
- Read upRead up
- Exclude checks
Disallow Magic Numbers (no-magic-numbers)
'Magic numbers' are numbers that occur multiple time in code without an explicit meaning. They should preferably be replaced by named constants.
var now = Date.now(),
inOneHour = now + (60 * 60 * 1000);
Rule Details
The no-magic-numbers
rule aims to make code more readable and refactoring easier by ensuring that special numbers
are declared as constants to make their meaning explicit.
Examples of incorrect code for this rule:
/*eslint no-magic-numbers: "error"*/
var dutyFreePrice = 100,
finalPrice = dutyFreePrice + (dutyFreePrice * 0.25);
/*eslint no-magic-numbers: "error"*/
var data = ['foo', 'bar', 'baz'];
var dataLast = data[2];
/*eslint no-magic-numbers: "error"*/
var SECONDS;
SECONDS = 60;
Examples of correct code for this rule:
/*eslint no-magic-numbers: "error"*/
var TAX = 0.25;
var dutyFreePrice = 100,
finalPrice = dutyFreePrice + (dutyFreePrice * TAX);
Options
ignore
An array of numbers to ignore. It's set to []
by default.
If provided, it must be an Array
.
Examples of correct code for the sample { "ignore": [1] }
option:
/*eslint no-magic-numbers: ["error", { "ignore": [1] }]*/
var data = ['foo', 'bar', 'baz'];
var dataLast = data.length && data[data.length - 1];
ignoreArrayIndexes
A boolean to specify if numbers used as array indexes are considered okay. false
by default.
Examples of correct code for the { "ignoreArrayIndexes": true }
option:
/*eslint no-magic-numbers: ["error", { "ignoreArrayIndexes": true }]*/
var data = ['foo', 'bar', 'baz'];
var dataLast = data[2];
enforceConst
A boolean to specify if we should check for the const keyword in variable declaration of numbers. false
by default.
Examples of incorrect code for the { "enforceConst": true }
option:
/*eslint no-magic-numbers: ["error", { "enforceConst": true }]*/
var TAX = 0.25;
var dutyFreePrice = 100,
finalPrice = dutyFreePrice + (dutyFreePrice * TAX);
detectObjects
A boolean to specify if we should detect numbers when setting object properties for example. false
by default.
Examples of incorrect code for the { "detectObjects": true }
option:
/*eslint no-magic-numbers: ["error", { "detectObjects": true }]*/
var magic = {
tax: 0.25
};
var dutyFreePrice = 100,
finalPrice = dutyFreePrice + (dutyFreePrice * magic.tax);
Examples of correct code for the { "detectObjects": true }
option:
/*eslint no-magic-numbers: ["error", { "detectObjects": true }]*/
var TAX = 0.25;
var magic = {
tax: TAX
};
var dutyFreePrice = 100,
finalPrice = dutyFreePrice + (dutyFreePrice * magic.tax);
Source: http://eslint.org/docs/rules/
Use the rest parameters instead of 'arguments'. Open
var from = arguments.length <= 1 || arguments[1] === undefined ? null : arguments[1];
- Read upRead up
- Exclude checks
Suggest using the rest parameters instead of arguments
(prefer-rest-params)
There are rest parameters in ES2015.
We can use that feature for variadic functions instead of the arguments
variable.
arguments
does not have methods of Array.prototype
, so it's a bit of an inconvenience.
Rule Details
This rule is aimed to flag usage of arguments
variables.
Examples
Examples of incorrect code for this rule:
function foo() {
console.log(arguments);
}
function foo(action) {
var args = Array.prototype.slice.call(arguments, 1);
action.apply(null, args);
}
function foo(action) {
var args = [].slice.call(arguments, 1);
action.apply(null, args);
}
Examples of correct code for this rule:
function foo(...args) {
console.log(args);
}
function foo(action, ...args) {
action.apply(null, args); // or `action(...args)`, related to the `prefer-spread` rule.
}
// Note: the implicit arguments can be overwritten.
function foo(arguments) {
console.log(arguments); // This is the first argument.
}
function foo() {
var arguments = 0;
console.log(arguments); // This is a local variable.
}
When Not To Use It
This rule should not be used in ES3/5 environments.
In ES2015 (ES6) or later, if you don't want to be notified about arguments
variables, then it's safe to disable this rule.
Related Rules
- [prefer-spread](prefer-spread.md) Source: http://eslint.org/docs/rules/