Showing 1,940 of 1,940 total issues
Expected '===' and instead saw '=='. Open
if(this.loaded[this.api] == false)
- Read upRead up
- Exclude checks
Require === and !== (eqeqeq)
It is considered good practice to use the type-safe equality operators ===
and !==
instead of their regular counterparts ==
and !=
.
The reason for this is that ==
and !=
do type coercion which follows the rather obscure Abstract Equality Comparison Algorithm.
For instance, the following statements are all considered true
:
[] == false
[] == ![]
3 == "03"
If one of those occurs in an innocent-looking statement such as a == b
the actual problem is very difficult to spot.
Rule Details
This rule is aimed at eliminating the type-unsafe equality operators.
Examples of incorrect code for this rule:
/*eslint eqeqeq: "error"*/
if (x == 42) { }
if ("" == text) { }
if (obj.getStuff() != undefined) { }
The --fix
option on the command line automatically fixes some problems reported by this rule. A problem is only fixed if one of the operands is a typeof
expression, or if both operands are literals with the same type.
Options
always
The "always"
option (default) enforces the use of ===
and !==
in every situation (except when you opt-in to more specific handling of null
[see below]).
Examples of incorrect code for the "always"
option:
/*eslint eqeqeq: ["error", "always"]*/
a == b
foo == true
bananas != 1
value == undefined
typeof foo == 'undefined'
'hello' != 'world'
0 == 0
true == true
foo == null
Examples of correct code for the "always"
option:
/*eslint eqeqeq: ["error", "always"]*/
a === b
foo === true
bananas !== 1
value === undefined
typeof foo === 'undefined'
'hello' !== 'world'
0 === 0
true === true
foo === null
This rule optionally takes a second argument, which should be an object with the following supported properties:
-
"null"
: Customize how this rule treatsnull
literals. Possible values:-
always
(default) - Always use === or !==. -
never
- Never use === or !== withnull
. -
ignore
- Do not apply this rule tonull
.
-
smart
The "smart"
option enforces the use of ===
and !==
except for these cases:
- Comparing two literal values
- Evaluating the value of
typeof
- Comparing against
null
Examples of incorrect code for the "smart"
option:
/*eslint eqeqeq: ["error", "smart"]*/
// comparing two variables requires ===
a == b
// only one side is a literal
foo == true
bananas != 1
// comparing to undefined requires ===
value == undefined
Examples of correct code for the "smart"
option:
/*eslint eqeqeq: ["error", "smart"]*/
typeof foo == 'undefined'
'hello' != 'world'
0 == 0
true == true
foo == null
allow-null
Deprecated: Instead of using this option use "always" and pass a "null" option property with value "ignore". This will tell eslint to always enforce strict equality except when comparing with the null
literal.
["error", "always", {"null": "ignore"}]
When Not To Use It
If you don't want to enforce a style for using equality operators, then it's safe to disable this rule. Source: http://eslint.org/docs/rules/
'i' is already defined. Open
for(var i = 0, length = this.polylines.length; i < length; i++){
- Read upRead up
- Exclude checks
disallow variable redeclaration (no-redeclare)
In JavaScript, it's possible to redeclare the same variable name using var
. This can lead to confusion as to where the variable is actually declared and initialized.
Rule Details
This rule is aimed at eliminating variables that have multiple declarations in the same scope.
Examples of incorrect code for this rule:
/*eslint no-redeclare: "error"*/
var a = 3;
var a = 10;
Examples of correct code for this rule:
/*eslint no-redeclare: "error"*/
var a = 3;
// ...
a = 10;
Options
This rule takes one optional argument, an object with a boolean property "builtinGlobals"
. It defaults to false
.
If set to true
, this rule also checks redeclaration of built-in globals, such as Object
, Array
, Number
...
builtinGlobals
Examples of incorrect code for the { "builtinGlobals": true }
option:
/*eslint no-redeclare: ["error", { "builtinGlobals": true }]*/
var Object = 0;
Examples of incorrect code for the { "builtinGlobals": true }
option and the browser
environment:
/*eslint no-redeclare: ["error", { "builtinGlobals": true }]*/
/*eslint-env browser*/
var top = 0;
The browser
environment has many built-in global variables (for example, top
). Some of built-in global variables cannot be redeclared.
Source: http://eslint.org/docs/rules/
'theInfo' is already defined. Open
var theInfo = this.infoDiv;
- Read upRead up
- Exclude checks
disallow variable redeclaration (no-redeclare)
In JavaScript, it's possible to redeclare the same variable name using var
. This can lead to confusion as to where the variable is actually declared and initialized.
Rule Details
This rule is aimed at eliminating variables that have multiple declarations in the same scope.
Examples of incorrect code for this rule:
/*eslint no-redeclare: "error"*/
var a = 3;
var a = 10;
Examples of correct code for this rule:
/*eslint no-redeclare: "error"*/
var a = 3;
// ...
a = 10;
Options
This rule takes one optional argument, an object with a boolean property "builtinGlobals"
. It defaults to false
.
If set to true
, this rule also checks redeclaration of built-in globals, such as Object
, Array
, Number
...
builtinGlobals
Examples of incorrect code for the { "builtinGlobals": true }
option:
/*eslint no-redeclare: ["error", { "builtinGlobals": true }]*/
var Object = 0;
Examples of incorrect code for the { "builtinGlobals": true }
option and the browser
environment:
/*eslint no-redeclare: ["error", { "builtinGlobals": true }]*/
/*eslint-env browser*/
var top = 0;
The browser
environment has many built-in global variables (for example, top
). Some of built-in global variables cannot be redeclared.
Source: http://eslint.org/docs/rules/
Unexpected alert. Open
alert(this.api + ' not supported by Mapstraction.removeAllPolylines');
- Read upRead up
- Exclude checks
Disallow Use of Alert (no-alert)
JavaScript's alert
, confirm
, and prompt
functions are widely considered to be obtrusive as UI elements and should be replaced by a more appropriate custom UI implementation. Furthermore, alert
is often used while debugging code, which should be removed before deployment to production.
alert("here!");
Rule Details
This rule is aimed at catching debugging code that should be removed and popup UI elements that should be replaced with less obtrusive, custom UIs. As such, it will warn when it encounters alert
, prompt
, and confirm
function calls which are not shadowed.
Examples of incorrect code for this rule:
/*eslint no-alert: "error"*/
alert("here!");
confirm("Are you sure?");
prompt("What's your name?", "John Doe");
Examples of correct code for this rule:
/*eslint no-alert: "error"*/
customAlert("Something happened!");
customConfirm("Are you sure?");
customPrompt("Who are you?");
function foo() {
var alert = myCustomLib.customAlert;
alert();
}
Related Rules
- [no-console](no-console.md)
- [no-debugger](no-debugger.md) Source: http://eslint.org/docs/rules/
Expected '!==' and instead saw '!='. Open
if (pan_zoom_widget != "MMWidget") {
- Read upRead up
- Exclude checks
Require === and !== (eqeqeq)
It is considered good practice to use the type-safe equality operators ===
and !==
instead of their regular counterparts ==
and !=
.
The reason for this is that ==
and !=
do type coercion which follows the rather obscure Abstract Equality Comparison Algorithm.
For instance, the following statements are all considered true
:
[] == false
[] == ![]
3 == "03"
If one of those occurs in an innocent-looking statement such as a == b
the actual problem is very difficult to spot.
Rule Details
This rule is aimed at eliminating the type-unsafe equality operators.
Examples of incorrect code for this rule:
/*eslint eqeqeq: "error"*/
if (x == 42) { }
if ("" == text) { }
if (obj.getStuff() != undefined) { }
The --fix
option on the command line automatically fixes some problems reported by this rule. A problem is only fixed if one of the operands is a typeof
expression, or if both operands are literals with the same type.
Options
always
The "always"
option (default) enforces the use of ===
and !==
in every situation (except when you opt-in to more specific handling of null
[see below]).
Examples of incorrect code for the "always"
option:
/*eslint eqeqeq: ["error", "always"]*/
a == b
foo == true
bananas != 1
value == undefined
typeof foo == 'undefined'
'hello' != 'world'
0 == 0
true == true
foo == null
Examples of correct code for the "always"
option:
/*eslint eqeqeq: ["error", "always"]*/
a === b
foo === true
bananas !== 1
value === undefined
typeof foo === 'undefined'
'hello' !== 'world'
0 === 0
true === true
foo === null
This rule optionally takes a second argument, which should be an object with the following supported properties:
-
"null"
: Customize how this rule treatsnull
literals. Possible values:-
always
(default) - Always use === or !==. -
never
- Never use === or !== withnull
. -
ignore
- Do not apply this rule tonull
.
-
smart
The "smart"
option enforces the use of ===
and !==
except for these cases:
- Comparing two literal values
- Evaluating the value of
typeof
- Comparing against
null
Examples of incorrect code for the "smart"
option:
/*eslint eqeqeq: ["error", "smart"]*/
// comparing two variables requires ===
a == b
// only one side is a literal
foo == true
bananas != 1
// comparing to undefined requires ===
value == undefined
Examples of correct code for the "smart"
option:
/*eslint eqeqeq: ["error", "smart"]*/
typeof foo == 'undefined'
'hello' != 'world'
0 == 0
true == true
foo == null
allow-null
Deprecated: Instead of using this option use "always" and pass a "null" option property with value "ignore". This will tell eslint to always enforce strict equality except when comparing with the null
literal.
["error", "always", {"null": "ignore"}]
When Not To Use It
If you don't want to enforce a style for using equality operators, then it's safe to disable this rule. Source: http://eslint.org/docs/rules/
The body of a for-in should be wrapped in an if statement to filter unwanted properties from the prototype. Open
for (var key in this.attributes) {
- Read upRead up
- Exclude checks
Require Guarding for-in (guard-for-in)
Looping over objects with a for in
loop will include properties that are inherited through the prototype chain. This behavior can lead to unexpected items in your for loop.
for (key in foo) {
doSomething(key);
}
Note that simply checking foo.hasOwnProperty(key)
is likely to cause an error in some cases; see [no-prototype-builtins](no-prototype-builtins.md).
Rule Details
This rule is aimed at preventing unexpected behavior that could arise from using a for in
loop without filtering the results in the loop. As such, it will warn when for in
loops do not filter their results with an if
statement.
Examples of incorrect code for this rule:
/*eslint guard-for-in: "error"*/
for (key in foo) {
doSomething(key);
}
Examples of correct code for this rule:
/*eslint guard-for-in: "error"*/
for (key in foo) {
if (Object.prototype.hasOwnProperty.call(foo, key)) {
doSomething(key);
}
if ({}.hasOwnProperty.call(foo, key)) {
doSomething(key);
}
}
Related Rules
- [no-prototype-builtins](no-prototype-builtins.md)
Further Reading
Expected '===' and instead saw '=='. Open
if(this.loaded[this.api] == false)
- Read upRead up
- Exclude checks
Require === and !== (eqeqeq)
It is considered good practice to use the type-safe equality operators ===
and !==
instead of their regular counterparts ==
and !=
.
The reason for this is that ==
and !=
do type coercion which follows the rather obscure Abstract Equality Comparison Algorithm.
For instance, the following statements are all considered true
:
[] == false
[] == ![]
3 == "03"
If one of those occurs in an innocent-looking statement such as a == b
the actual problem is very difficult to spot.
Rule Details
This rule is aimed at eliminating the type-unsafe equality operators.
Examples of incorrect code for this rule:
/*eslint eqeqeq: "error"*/
if (x == 42) { }
if ("" == text) { }
if (obj.getStuff() != undefined) { }
The --fix
option on the command line automatically fixes some problems reported by this rule. A problem is only fixed if one of the operands is a typeof
expression, or if both operands are literals with the same type.
Options
always
The "always"
option (default) enforces the use of ===
and !==
in every situation (except when you opt-in to more specific handling of null
[see below]).
Examples of incorrect code for the "always"
option:
/*eslint eqeqeq: ["error", "always"]*/
a == b
foo == true
bananas != 1
value == undefined
typeof foo == 'undefined'
'hello' != 'world'
0 == 0
true == true
foo == null
Examples of correct code for the "always"
option:
/*eslint eqeqeq: ["error", "always"]*/
a === b
foo === true
bananas !== 1
value === undefined
typeof foo === 'undefined'
'hello' !== 'world'
0 === 0
true === true
foo === null
This rule optionally takes a second argument, which should be an object with the following supported properties:
-
"null"
: Customize how this rule treatsnull
literals. Possible values:-
always
(default) - Always use === or !==. -
never
- Never use === or !== withnull
. -
ignore
- Do not apply this rule tonull
.
-
smart
The "smart"
option enforces the use of ===
and !==
except for these cases:
- Comparing two literal values
- Evaluating the value of
typeof
- Comparing against
null
Examples of incorrect code for the "smart"
option:
/*eslint eqeqeq: ["error", "smart"]*/
// comparing two variables requires ===
a == b
// only one side is a literal
foo == true
bananas != 1
// comparing to undefined requires ===
value == undefined
Examples of correct code for the "smart"
option:
/*eslint eqeqeq: ["error", "smart"]*/
typeof foo == 'undefined'
'hello' != 'world'
0 == 0
true == true
foo == null
allow-null
Deprecated: Instead of using this option use "always" and pass a "null" option property with value "ignore". This will tell eslint to always enforce strict equality except when comparing with the null
literal.
["error", "always", {"null": "ignore"}]
When Not To Use It
If you don't want to enforce a style for using equality operators, then it's safe to disable this rule. Source: http://eslint.org/docs/rules/
Expected '===' and instead saw '=='. Open
if(this.loaded[this.api] == false)
- Read upRead up
- Exclude checks
Require === and !== (eqeqeq)
It is considered good practice to use the type-safe equality operators ===
and !==
instead of their regular counterparts ==
and !=
.
The reason for this is that ==
and !=
do type coercion which follows the rather obscure Abstract Equality Comparison Algorithm.
For instance, the following statements are all considered true
:
[] == false
[] == ![]
3 == "03"
If one of those occurs in an innocent-looking statement such as a == b
the actual problem is very difficult to spot.
Rule Details
This rule is aimed at eliminating the type-unsafe equality operators.
Examples of incorrect code for this rule:
/*eslint eqeqeq: "error"*/
if (x == 42) { }
if ("" == text) { }
if (obj.getStuff() != undefined) { }
The --fix
option on the command line automatically fixes some problems reported by this rule. A problem is only fixed if one of the operands is a typeof
expression, or if both operands are literals with the same type.
Options
always
The "always"
option (default) enforces the use of ===
and !==
in every situation (except when you opt-in to more specific handling of null
[see below]).
Examples of incorrect code for the "always"
option:
/*eslint eqeqeq: ["error", "always"]*/
a == b
foo == true
bananas != 1
value == undefined
typeof foo == 'undefined'
'hello' != 'world'
0 == 0
true == true
foo == null
Examples of correct code for the "always"
option:
/*eslint eqeqeq: ["error", "always"]*/
a === b
foo === true
bananas !== 1
value === undefined
typeof foo === 'undefined'
'hello' !== 'world'
0 === 0
true === true
foo === null
This rule optionally takes a second argument, which should be an object with the following supported properties:
-
"null"
: Customize how this rule treatsnull
literals. Possible values:-
always
(default) - Always use === or !==. -
never
- Never use === or !== withnull
. -
ignore
- Do not apply this rule tonull
.
-
smart
The "smart"
option enforces the use of ===
and !==
except for these cases:
- Comparing two literal values
- Evaluating the value of
typeof
- Comparing against
null
Examples of incorrect code for the "smart"
option:
/*eslint eqeqeq: ["error", "smart"]*/
// comparing two variables requires ===
a == b
// only one side is a literal
foo == true
bananas != 1
// comparing to undefined requires ===
value == undefined
Examples of correct code for the "smart"
option:
/*eslint eqeqeq: ["error", "smart"]*/
typeof foo == 'undefined'
'hello' != 'world'
0 == 0
true == true
foo == null
allow-null
Deprecated: Instead of using this option use "always" and pass a "null" option property with value "ignore". This will tell eslint to always enforce strict equality except when comparing with the null
literal.
["error", "always", {"null": "ignore"}]
When Not To Use It
If you don't want to enforce a style for using equality operators, then it's safe to disable this rule. Source: http://eslint.org/docs/rules/
Expected '===' and instead saw '=='. Open
if (map.controls[i].displayClass == "olControlNavigation") {
- Read upRead up
- Exclude checks
Require === and !== (eqeqeq)
It is considered good practice to use the type-safe equality operators ===
and !==
instead of their regular counterparts ==
and !=
.
The reason for this is that ==
and !=
do type coercion which follows the rather obscure Abstract Equality Comparison Algorithm.
For instance, the following statements are all considered true
:
[] == false
[] == ![]
3 == "03"
If one of those occurs in an innocent-looking statement such as a == b
the actual problem is very difficult to spot.
Rule Details
This rule is aimed at eliminating the type-unsafe equality operators.
Examples of incorrect code for this rule:
/*eslint eqeqeq: "error"*/
if (x == 42) { }
if ("" == text) { }
if (obj.getStuff() != undefined) { }
The --fix
option on the command line automatically fixes some problems reported by this rule. A problem is only fixed if one of the operands is a typeof
expression, or if both operands are literals with the same type.
Options
always
The "always"
option (default) enforces the use of ===
and !==
in every situation (except when you opt-in to more specific handling of null
[see below]).
Examples of incorrect code for the "always"
option:
/*eslint eqeqeq: ["error", "always"]*/
a == b
foo == true
bananas != 1
value == undefined
typeof foo == 'undefined'
'hello' != 'world'
0 == 0
true == true
foo == null
Examples of correct code for the "always"
option:
/*eslint eqeqeq: ["error", "always"]*/
a === b
foo === true
bananas !== 1
value === undefined
typeof foo === 'undefined'
'hello' !== 'world'
0 === 0
true === true
foo === null
This rule optionally takes a second argument, which should be an object with the following supported properties:
-
"null"
: Customize how this rule treatsnull
literals. Possible values:-
always
(default) - Always use === or !==. -
never
- Never use === or !== withnull
. -
ignore
- Do not apply this rule tonull
.
-
smart
The "smart"
option enforces the use of ===
and !==
except for these cases:
- Comparing two literal values
- Evaluating the value of
typeof
- Comparing against
null
Examples of incorrect code for the "smart"
option:
/*eslint eqeqeq: ["error", "smart"]*/
// comparing two variables requires ===
a == b
// only one side is a literal
foo == true
bananas != 1
// comparing to undefined requires ===
value == undefined
Examples of correct code for the "smart"
option:
/*eslint eqeqeq: ["error", "smart"]*/
typeof foo == 'undefined'
'hello' != 'world'
0 == 0
true == true
foo == null
allow-null
Deprecated: Instead of using this option use "always" and pass a "null" option property with value "ignore". This will tell eslint to always enforce strict equality except when comparing with the null
literal.
["error", "always", {"null": "ignore"}]
When Not To Use It
If you don't want to enforce a style for using equality operators, then it's safe to disable this rule. Source: http://eslint.org/docs/rules/
Unexpected alert. Open
alert(this.api + ' not supported by Mapstraction.setMapType');
- Read upRead up
- Exclude checks
Disallow Use of Alert (no-alert)
JavaScript's alert
, confirm
, and prompt
functions are widely considered to be obtrusive as UI elements and should be replaced by a more appropriate custom UI implementation. Furthermore, alert
is often used while debugging code, which should be removed before deployment to production.
alert("here!");
Rule Details
This rule is aimed at catching debugging code that should be removed and popup UI elements that should be replaced with less obtrusive, custom UIs. As such, it will warn when it encounters alert
, prompt
, and confirm
function calls which are not shadowed.
Examples of incorrect code for this rule:
/*eslint no-alert: "error"*/
alert("here!");
confirm("Are you sure?");
prompt("What's your name?", "John Doe");
Examples of correct code for this rule:
/*eslint no-alert: "error"*/
customAlert("Something happened!");
customConfirm("Are you sure?");
customPrompt("Who are you?");
function foo() {
var alert = myCustomLib.customAlert;
alert();
}
Related Rules
- [no-console](no-console.md)
- [no-debugger](no-debugger.md) Source: http://eslint.org/docs/rules/
'i' is already defined. Open
for(var i = 0, length = this.polylines.length; i < length; i++){
- Read upRead up
- Exclude checks
disallow variable redeclaration (no-redeclare)
In JavaScript, it's possible to redeclare the same variable name using var
. This can lead to confusion as to where the variable is actually declared and initialized.
Rule Details
This rule is aimed at eliminating variables that have multiple declarations in the same scope.
Examples of incorrect code for this rule:
/*eslint no-redeclare: "error"*/
var a = 3;
var a = 10;
Examples of correct code for this rule:
/*eslint no-redeclare: "error"*/
var a = 3;
// ...
a = 10;
Options
This rule takes one optional argument, an object with a boolean property "builtinGlobals"
. It defaults to false
.
If set to true
, this rule also checks redeclaration of built-in globals, such as Object
, Array
, Number
...
builtinGlobals
Examples of incorrect code for the { "builtinGlobals": true }
option:
/*eslint no-redeclare: ["error", { "builtinGlobals": true }]*/
var Object = 0;
Examples of incorrect code for the { "builtinGlobals": true }
option and the browser
environment:
/*eslint no-redeclare: ["error", { "builtinGlobals": true }]*/
/*eslint-env browser*/
var top = 0;
The browser
environment has many built-in global variables (for example, top
). Some of built-in global variables cannot be redeclared.
Source: http://eslint.org/docs/rules/
It's not necessary to initialize 'point' to undefined. Open
var point = undefined;
- Read upRead up
- Exclude checks
Disallow Initializing to undefined (no-undef-init)
In JavaScript, a variable that is declared and not initialized to any value automatically gets the value of undefined
. For example:
var foo;
console.log(foo === undefined); // true
It's therefore unnecessary to initialize a variable to undefined
, such as:
var foo = undefined;
It's considered a best practice to avoid initializing variables to undefined
.
Rule Details
This rule aims to eliminate variable declarations that initialize to undefined
.
Examples of incorrect code for this rule:
/*eslint no-undef-init: "error"*/
/*eslint-env es6*/
var foo = undefined;
let bar = undefined;
Examples of correct code for this rule:
/*eslint no-undef-init: "error"*/
/*eslint-env es6*/
var foo;
let bar;
const baz = undefined;
When Not To Use It
There is one situation where initializing to undefined
behaves differently than omitting the initialization, and that's when a var
declaration occurs inside of a loop. For example:
Example of incorrect code for this rule:
for (i = 0; i < 10; i++) {
var x = undefined;
console.log(x);
x = i;
}
In this case, the var x
is hoisted out of the loop, effectively creating:
var x;
for (i = 0; i < 10; i++) {
x = undefined;
console.log(x);
x = i;
}
If you were to remove the initialization, then the behavior of the loop changes:
for (i = 0; i < 10; i++) {
var x;
console.log(x);
x = i;
}
This code is equivalent to:
var x;
for (i = 0; i < 10; i++) {
console.log(x);
x = i;
}
This produces a different outcome than defining var x = undefined
in the loop, as x
is no longer reset to undefined
each time through the loop.
If you're using such an initialization inside of a loop, then you should disable this rule.
Example of correct code for this rule, because it is disabled on a specific line:
/*eslint no-undef-init: "error"*/
for (i = 0; i < 10; i++) {
var x = undefined; // eslint-disable-line no-undef-init
console.log(x);
x = i;
}
Related Rules
- [no-undefined](no-undefined.md)
- [no-void](no-void.md) Source: http://eslint.org/docs/rules/
Unexpected alert. Open
alert(this.api + ' not supported by Mapstraction.addMarker');
- Read upRead up
- Exclude checks
Disallow Use of Alert (no-alert)
JavaScript's alert
, confirm
, and prompt
functions are widely considered to be obtrusive as UI elements and should be replaced by a more appropriate custom UI implementation. Furthermore, alert
is often used while debugging code, which should be removed before deployment to production.
alert("here!");
Rule Details
This rule is aimed at catching debugging code that should be removed and popup UI elements that should be replaced with less obtrusive, custom UIs. As such, it will warn when it encounters alert
, prompt
, and confirm
function calls which are not shadowed.
Examples of incorrect code for this rule:
/*eslint no-alert: "error"*/
alert("here!");
confirm("Are you sure?");
prompt("What's your name?", "John Doe");
Examples of correct code for this rule:
/*eslint no-alert: "error"*/
customAlert("Something happened!");
customConfirm("Are you sure?");
customPrompt("Who are you?");
function foo() {
var alert = myCustomLib.customAlert;
alert();
}
Related Rules
- [no-console](no-console.md)
- [no-debugger](no-debugger.md) Source: http://eslint.org/docs/rules/
'center' is already defined. Open
var center = new LatLonPoint((sw.lat + ne.lat)/2, (ne.lon + sw.lon)/2);
- Read upRead up
- Exclude checks
disallow variable redeclaration (no-redeclare)
In JavaScript, it's possible to redeclare the same variable name using var
. This can lead to confusion as to where the variable is actually declared and initialized.
Rule Details
This rule is aimed at eliminating variables that have multiple declarations in the same scope.
Examples of incorrect code for this rule:
/*eslint no-redeclare: "error"*/
var a = 3;
var a = 10;
Examples of correct code for this rule:
/*eslint no-redeclare: "error"*/
var a = 3;
// ...
a = 10;
Options
This rule takes one optional argument, an object with a boolean property "builtinGlobals"
. It defaults to false
.
If set to true
, this rule also checks redeclaration of built-in globals, such as Object
, Array
, Number
...
builtinGlobals
Examples of incorrect code for the { "builtinGlobals": true }
option:
/*eslint no-redeclare: ["error", { "builtinGlobals": true }]*/
var Object = 0;
Examples of incorrect code for the { "builtinGlobals": true }
option and the browser
environment:
/*eslint no-redeclare: ["error", { "builtinGlobals": true }]*/
/*eslint-env browser*/
var top = 0;
The browser
environment has many built-in global variables (for example, top
). Some of built-in global variables cannot be redeclared.
Source: http://eslint.org/docs/rules/
Use ‘===’ to compare with ‘null’. Open
if(options != null && options['pan']) { map.PanToLatLong(point.toMicrosoft()); }
- Read upRead up
- Exclude checks
Disallow Null Comparisons (no-eq-null)
Comparing to null
without a type-checking operator (==
or !=
), can have unintended results as the comparison will evaluate to true when comparing to not just a null
, but also an undefined
value.
if (foo == null) {
bar();
}
Rule Details
The no-eq-null
rule aims reduce potential bug and unwanted behavior by ensuring that comparisons to null
only match null
, and not also undefined
. As such it will flag comparisons to null when using ==
and !=
.
Examples of incorrect code for this rule:
/*eslint no-eq-null: "error"*/
if (foo == null) {
bar();
}
while (qux != null) {
baz();
}
Examples of correct code for this rule:
/*eslint no-eq-null: "error"*/
if (foo === null) {
bar();
}
while (qux !== null) {
baz();
}
Source: http://eslint.org/docs/rules/
Unexpected alert. Open
alert(this.api + ' not supported by Mapstraction.declutterMarkers');
- Read upRead up
- Exclude checks
Disallow Use of Alert (no-alert)
JavaScript's alert
, confirm
, and prompt
functions are widely considered to be obtrusive as UI elements and should be replaced by a more appropriate custom UI implementation. Furthermore, alert
is often used while debugging code, which should be removed before deployment to production.
alert("here!");
Rule Details
This rule is aimed at catching debugging code that should be removed and popup UI elements that should be replaced with less obtrusive, custom UIs. As such, it will warn when it encounters alert
, prompt
, and confirm
function calls which are not shadowed.
Examples of incorrect code for this rule:
/*eslint no-alert: "error"*/
alert("here!");
confirm("Are you sure?");
prompt("What's your name?", "John Doe");
Examples of correct code for this rule:
/*eslint no-alert: "error"*/
customAlert("Something happened!");
customConfirm("Are you sure?");
customPrompt("Who are you?");
function foo() {
var alert = myCustomLib.customAlert;
alert();
}
Related Rules
- [no-console](no-console.md)
- [no-debugger](no-debugger.md) Source: http://eslint.org/docs/rules/
Unexpected alert. Open
alert(this.api + "not supported by Mapstraction.addImageOverlay not supported");
- Read upRead up
- Exclude checks
Disallow Use of Alert (no-alert)
JavaScript's alert
, confirm
, and prompt
functions are widely considered to be obtrusive as UI elements and should be replaced by a more appropriate custom UI implementation. Furthermore, alert
is often used while debugging code, which should be removed before deployment to production.
alert("here!");
Rule Details
This rule is aimed at catching debugging code that should be removed and popup UI elements that should be replaced with less obtrusive, custom UIs. As such, it will warn when it encounters alert
, prompt
, and confirm
function calls which are not shadowed.
Examples of incorrect code for this rule:
/*eslint no-alert: "error"*/
alert("here!");
confirm("Are you sure?");
prompt("What's your name?", "John Doe");
Examples of correct code for this rule:
/*eslint no-alert: "error"*/
customAlert("Something happened!");
customConfirm("Are you sure?");
customPrompt("Who are you?");
function foo() {
var alert = myCustomLib.customAlert;
alert();
}
Related Rules
- [no-console](no-console.md)
- [no-debugger](no-debugger.md) Source: http://eslint.org/docs/rules/
Expected '===' and instead saw '=='. Open
if(this.loaded[this.api] == false)
- Read upRead up
- Exclude checks
Require === and !== (eqeqeq)
It is considered good practice to use the type-safe equality operators ===
and !==
instead of their regular counterparts ==
and !=
.
The reason for this is that ==
and !=
do type coercion which follows the rather obscure Abstract Equality Comparison Algorithm.
For instance, the following statements are all considered true
:
[] == false
[] == ![]
3 == "03"
If one of those occurs in an innocent-looking statement such as a == b
the actual problem is very difficult to spot.
Rule Details
This rule is aimed at eliminating the type-unsafe equality operators.
Examples of incorrect code for this rule:
/*eslint eqeqeq: "error"*/
if (x == 42) { }
if ("" == text) { }
if (obj.getStuff() != undefined) { }
The --fix
option on the command line automatically fixes some problems reported by this rule. A problem is only fixed if one of the operands is a typeof
expression, or if both operands are literals with the same type.
Options
always
The "always"
option (default) enforces the use of ===
and !==
in every situation (except when you opt-in to more specific handling of null
[see below]).
Examples of incorrect code for the "always"
option:
/*eslint eqeqeq: ["error", "always"]*/
a == b
foo == true
bananas != 1
value == undefined
typeof foo == 'undefined'
'hello' != 'world'
0 == 0
true == true
foo == null
Examples of correct code for the "always"
option:
/*eslint eqeqeq: ["error", "always"]*/
a === b
foo === true
bananas !== 1
value === undefined
typeof foo === 'undefined'
'hello' !== 'world'
0 === 0
true === true
foo === null
This rule optionally takes a second argument, which should be an object with the following supported properties:
-
"null"
: Customize how this rule treatsnull
literals. Possible values:-
always
(default) - Always use === or !==. -
never
- Never use === or !== withnull
. -
ignore
- Do not apply this rule tonull
.
-
smart
The "smart"
option enforces the use of ===
and !==
except for these cases:
- Comparing two literal values
- Evaluating the value of
typeof
- Comparing against
null
Examples of incorrect code for the "smart"
option:
/*eslint eqeqeq: ["error", "smart"]*/
// comparing two variables requires ===
a == b
// only one side is a literal
foo == true
bananas != 1
// comparing to undefined requires ===
value == undefined
Examples of correct code for the "smart"
option:
/*eslint eqeqeq: ["error", "smart"]*/
typeof foo == 'undefined'
'hello' != 'world'
0 == 0
true == true
foo == null
allow-null
Deprecated: Instead of using this option use "always" and pass a "null" option property with value "ignore". This will tell eslint to always enforce strict equality except when comparing with the null
literal.
["error", "always", {"null": "ignore"}]
When Not To Use It
If you don't want to enforce a style for using equality operators, then it's safe to disable this rule. Source: http://eslint.org/docs/rules/
Expected '===' and instead saw '=='. Open
if(typeof(d.style.MozOpacity)=='string'){
- Read upRead up
- Exclude checks
Require === and !== (eqeqeq)
It is considered good practice to use the type-safe equality operators ===
and !==
instead of their regular counterparts ==
and !=
.
The reason for this is that ==
and !=
do type coercion which follows the rather obscure Abstract Equality Comparison Algorithm.
For instance, the following statements are all considered true
:
[] == false
[] == ![]
3 == "03"
If one of those occurs in an innocent-looking statement such as a == b
the actual problem is very difficult to spot.
Rule Details
This rule is aimed at eliminating the type-unsafe equality operators.
Examples of incorrect code for this rule:
/*eslint eqeqeq: "error"*/
if (x == 42) { }
if ("" == text) { }
if (obj.getStuff() != undefined) { }
The --fix
option on the command line automatically fixes some problems reported by this rule. A problem is only fixed if one of the operands is a typeof
expression, or if both operands are literals with the same type.
Options
always
The "always"
option (default) enforces the use of ===
and !==
in every situation (except when you opt-in to more specific handling of null
[see below]).
Examples of incorrect code for the "always"
option:
/*eslint eqeqeq: ["error", "always"]*/
a == b
foo == true
bananas != 1
value == undefined
typeof foo == 'undefined'
'hello' != 'world'
0 == 0
true == true
foo == null
Examples of correct code for the "always"
option:
/*eslint eqeqeq: ["error", "always"]*/
a === b
foo === true
bananas !== 1
value === undefined
typeof foo === 'undefined'
'hello' !== 'world'
0 === 0
true === true
foo === null
This rule optionally takes a second argument, which should be an object with the following supported properties:
-
"null"
: Customize how this rule treatsnull
literals. Possible values:-
always
(default) - Always use === or !==. -
never
- Never use === or !== withnull
. -
ignore
- Do not apply this rule tonull
.
-
smart
The "smart"
option enforces the use of ===
and !==
except for these cases:
- Comparing two literal values
- Evaluating the value of
typeof
- Comparing against
null
Examples of incorrect code for the "smart"
option:
/*eslint eqeqeq: ["error", "smart"]*/
// comparing two variables requires ===
a == b
// only one side is a literal
foo == true
bananas != 1
// comparing to undefined requires ===
value == undefined
Examples of correct code for the "smart"
option:
/*eslint eqeqeq: ["error", "smart"]*/
typeof foo == 'undefined'
'hello' != 'world'
0 == 0
true == true
foo == null
allow-null
Deprecated: Instead of using this option use "always" and pass a "null" option property with value "ignore". This will tell eslint to always enforce strict equality except when comparing with the null
literal.
["error", "always", {"null": "ignore"}]
When Not To Use It
If you don't want to enforce a style for using equality operators, then it's safe to disable this rule. Source: http://eslint.org/docs/rules/
Expected '===' and instead saw '=='. Open
if (type == Mapstraction.ROAD) {
- Read upRead up
- Exclude checks
Require === and !== (eqeqeq)
It is considered good practice to use the type-safe equality operators ===
and !==
instead of their regular counterparts ==
and !=
.
The reason for this is that ==
and !=
do type coercion which follows the rather obscure Abstract Equality Comparison Algorithm.
For instance, the following statements are all considered true
:
[] == false
[] == ![]
3 == "03"
If one of those occurs in an innocent-looking statement such as a == b
the actual problem is very difficult to spot.
Rule Details
This rule is aimed at eliminating the type-unsafe equality operators.
Examples of incorrect code for this rule:
/*eslint eqeqeq: "error"*/
if (x == 42) { }
if ("" == text) { }
if (obj.getStuff() != undefined) { }
The --fix
option on the command line automatically fixes some problems reported by this rule. A problem is only fixed if one of the operands is a typeof
expression, or if both operands are literals with the same type.
Options
always
The "always"
option (default) enforces the use of ===
and !==
in every situation (except when you opt-in to more specific handling of null
[see below]).
Examples of incorrect code for the "always"
option:
/*eslint eqeqeq: ["error", "always"]*/
a == b
foo == true
bananas != 1
value == undefined
typeof foo == 'undefined'
'hello' != 'world'
0 == 0
true == true
foo == null
Examples of correct code for the "always"
option:
/*eslint eqeqeq: ["error", "always"]*/
a === b
foo === true
bananas !== 1
value === undefined
typeof foo === 'undefined'
'hello' !== 'world'
0 === 0
true === true
foo === null
This rule optionally takes a second argument, which should be an object with the following supported properties:
-
"null"
: Customize how this rule treatsnull
literals. Possible values:-
always
(default) - Always use === or !==. -
never
- Never use === or !== withnull
. -
ignore
- Do not apply this rule tonull
.
-
smart
The "smart"
option enforces the use of ===
and !==
except for these cases:
- Comparing two literal values
- Evaluating the value of
typeof
- Comparing against
null
Examples of incorrect code for the "smart"
option:
/*eslint eqeqeq: ["error", "smart"]*/
// comparing two variables requires ===
a == b
// only one side is a literal
foo == true
bananas != 1
// comparing to undefined requires ===
value == undefined
Examples of correct code for the "smart"
option:
/*eslint eqeqeq: ["error", "smart"]*/
typeof foo == 'undefined'
'hello' != 'world'
0 == 0
true == true
foo == null
allow-null
Deprecated: Instead of using this option use "always" and pass a "null" option property with value "ignore". This will tell eslint to always enforce strict equality except when comparing with the null
literal.
["error", "always", {"null": "ignore"}]
When Not To Use It
If you don't want to enforce a style for using equality operators, then it's safe to disable this rule. Source: http://eslint.org/docs/rules/