Function resolve
has a Cognitive Complexity of 27 (exceeds 5 allowed). Consider refactoring. Open
resolve() {
if (this.reset.value == 1) {
this.masterState = this.slaveState = this.preset.value || 0;
} else if (this.en.value == 0) {
this.prevClockState = this.clockInp.value;
- Read upRead up
Cognitive Complexity
Cognitive Complexity is a measure of how difficult a unit of code is to intuitively understand. Unlike Cyclomatic Complexity, which determines how difficult your code will be to test, Cognitive Complexity tells you how difficult your code will be to read and comprehend.
A method's cognitive complexity is based on a few simple rules:
- Code is not considered more complex when it uses shorthand that the language provides for collapsing multiple statements into one
- Code is considered more complex for each "break in the linear flow of the code"
- Code is considered more complex when "flow breaking structures are nested"
Further reading
Avoid deeply nested control flow statements. Open
if (this.J.value && this.K.value) { this.masterState = 1 ^ this.slaveState; }
else if (this.J.value ^ this.K.value) { this.masterState = this.J.value; }
Unexpected use of '^'. Open
if (this.J.value && this.K.value) { this.masterState = 1 ^ this.slaveState; }
- Read upRead up
- Exclude checks
disallow bitwise operators (no-bitwise)
The use of bitwise operators in JavaScript is very rare and often &
or |
is simply a mistyped &&
or ||
, which will lead to unexpected behavior.
var x = y | z;
Rule Details
This rule disallows bitwise operators.
Examples of incorrect code for this rule:
/*eslint no-bitwise: "error"*/
var x = y | z;
var x = y & z;
var x = y ^ z;
var x = ~ z;
var x = y << z;
var x = y >> z;
var x = y >>> z;
x |= y;
x &= y;
x ^= y;
x <<= y;
x >>= y;
x >>>= y;
Examples of correct code for this rule:
/*eslint no-bitwise: "error"*/
var x = y || z;
var x = y && z;
var x = y > z;
var x = y < z;
x += y;
Options
This rule has an object option:
-
"allow"
: Allows a list of bitwise operators to be used as exceptions. -
"int32Hint"
: Allows the use of bitwise OR in|0
pattern for type casting.
allow
Examples of correct code for this rule with the { "allow": ["~"] }
option:
/*eslint no-bitwise: ["error", { "allow": ["~"] }] */
~[1,2,3].indexOf(1) === -1;
int32Hint
Examples of correct code for this rule with the { "int32Hint": true }
option:
/*eslint no-bitwise: ["error", { "int32Hint": true }] */
var b = a|0;
Source: http://eslint.org/docs/rules/
Unexpected use of '^'. Open
if (this.J.value && this.K.value) { this.masterState = 1 ^ this.slaveState; }
- Read upRead up
- Exclude checks
disallow bitwise operators (no-bitwise)
The use of bitwise operators in JavaScript is very rare and often &
or |
is simply a mistyped &&
or ||
, which will lead to unexpected behavior.
var x = y | z;
Rule Details
This rule disallows bitwise operators.
Examples of incorrect code for this rule:
/*eslint no-bitwise: "error"*/
var x = y | z;
var x = y & z;
var x = y ^ z;
var x = ~ z;
var x = y << z;
var x = y >> z;
var x = y >>> z;
x |= y;
x &= y;
x ^= y;
x <<= y;
x >>= y;
x >>>= y;
Examples of correct code for this rule:
/*eslint no-bitwise: "error"*/
var x = y || z;
var x = y && z;
var x = y > z;
var x = y < z;
x += y;
Options
This rule has an object option:
-
"allow"
: Allows a list of bitwise operators to be used as exceptions. -
"int32Hint"
: Allows the use of bitwise OR in|0
pattern for type casting.
allow
Examples of correct code for this rule with the { "allow": ["~"] }
option:
/*eslint no-bitwise: ["error", { "allow": ["~"] }] */
~[1,2,3].indexOf(1) === -1;
int32Hint
Examples of correct code for this rule with the { "int32Hint": true }
option:
/*eslint no-bitwise: ["error", { "int32Hint": true }] */
var b = a|0;
Source: http://eslint.org/docs/rules/
Unexpected use of '^'. Open
else if (this.J.value ^ this.K.value) { this.masterState = this.J.value; }
- Read upRead up
- Exclude checks
disallow bitwise operators (no-bitwise)
The use of bitwise operators in JavaScript is very rare and often &
or |
is simply a mistyped &&
or ||
, which will lead to unexpected behavior.
var x = y | z;
Rule Details
This rule disallows bitwise operators.
Examples of incorrect code for this rule:
/*eslint no-bitwise: "error"*/
var x = y | z;
var x = y & z;
var x = y ^ z;
var x = ~ z;
var x = y << z;
var x = y >> z;
var x = y >>> z;
x |= y;
x &= y;
x ^= y;
x <<= y;
x >>= y;
x >>>= y;
Examples of correct code for this rule:
/*eslint no-bitwise: "error"*/
var x = y || z;
var x = y && z;
var x = y > z;
var x = y < z;
x += y;
Options
This rule has an object option:
-
"allow"
: Allows a list of bitwise operators to be used as exceptions. -
"int32Hint"
: Allows the use of bitwise OR in|0
pattern for type casting.
allow
Examples of correct code for this rule with the { "allow": ["~"] }
option:
/*eslint no-bitwise: ["error", { "allow": ["~"] }] */
~[1,2,3].indexOf(1) === -1;
int32Hint
Examples of correct code for this rule with the { "int32Hint": true }
option:
/*eslint no-bitwise: ["error", { "int32Hint": true }] */
var b = a|0;
Source: http://eslint.org/docs/rules/
Unexpected chained assignment. Open
this.masterState = this.slaveState = this.preset.value || 0;
- Read upRead up
- Exclude checks
Disallow Use of Chained Assignment Expressions (no-multi-assign)
Chaining the assignment of variables can lead to unexpected results and be difficult to read.
(function() {
const foo = bar = 0; // Did you mean `foo = bar == 0`?
bar = 1; // This will not fail since `bar` is not constant.
})();
console.log(bar); // This will output 1 since `bar` is not scoped.
Rule Details
This rule disallows using multiple assignments within a single statement.
Examples of incorrect code for this rule:
/*eslint no-multi-assign: "error"*/
var a = b = c = 5;
const foo = bar = "baz";
let a =
b =
c;
Examples of correct code for this rule:
/*eslint no-multi-assign: "error"*/
var a = 5;
var b = 5;
var c = 5;
const foo = "baz";
const bar = "baz";
let a = c;
let b = c;
Related Rules
- [max-statements-per-line](max-statements-per-line.md) Source: http://eslint.org/docs/rules/
Expected a line break after this opening brace. Open
import { correctWidth, lineTo, moveTo, fillText } from '../canvasApi';
- Read upRead up
- Exclude checks
enforce consistent line breaks inside braces (object-curly-newline)
A number of style guides require or disallow line breaks inside of object braces and other tokens.
Rule Details
This rule enforces consistent line breaks inside braces of object literals or destructuring assignments.
Options
This rule has either a string option:
-
"always"
requires line breaks inside braces -
"never"
disallows line breaks inside braces
Or an object option:
-
"multiline": true
requires line breaks if there are line breaks inside properties or between properties. Otherwise, it disallows line breaks. -
"minProperties"
requires line breaks if the number of properties is at least the given integer. By default, an error will also be reported if an object contains linebreaks and has fewer properties than the given integer. However, the second behavior is disabled if theconsistent
option is set totrue
-
"consistent": true
(default) requires that either both curly braces, or neither, directly enclose newlines. Note that enabling this option will also change the behavior of theminProperties
option. (SeeminProperties
above for more information)
You can specify different options for object literals, destructuring assignments, and named imports and exports:
{
"object-curly-newline": ["error", {
"ObjectExpression": "always",
"ObjectPattern": { "multiline": true },
"ImportDeclaration": "never",
"ExportDeclaration": { "multiline": true, "minProperties": 3 }
}]
}
-
"ObjectExpression"
configuration for object literals -
"ObjectPattern"
configuration for object patterns of destructuring assignments -
"ImportDeclaration"
configuration for named imports -
"ExportDeclaration"
configuration for named exports
always
Examples of incorrect code for this rule with the "always"
option:
/*eslint object-curly-newline: ["error", "always"]*/
/*eslint-env es6*/
let a = {};
let b = {foo: 1};
let c = {foo: 1, bar: 2};
let d = {foo: 1,
bar: 2};
let e = {foo() {
dosomething();
}};
let {} = obj;
let {f} = obj;
let {g, h} = obj;
let {i,
j} = obj;
let {k = function() {
dosomething();
}} = obj;
Examples of correct code for this rule with the "always"
option:
/*eslint object-curly-newline: ["error", "always"]*/
/*eslint-env es6*/
let a = {
};
let b = {
foo: 1
};
let c = {
foo: 1, bar: 2
};
let d = {
foo: 1,
bar: 2
};
let e = {
foo: function() {
dosomething();
}
};
let {
} = obj;
let {
f
} = obj;
let {
g, h
} = obj;
let {
i,
j
} = obj;
let {
k = function() {
dosomething();
}
} = obj;
never
Examples of incorrect code for this rule with the "never"
option:
/*eslint object-curly-newline: ["error", "never"]*/
/*eslint-env es6*/
let a = {
};
let b = {
foo: 1
};
let c = {
foo: 1, bar: 2
};
let d = {
foo: 1,
bar: 2
};
let e = {
foo: function() {
dosomething();
}
};
let {
} = obj;
let {
f
} = obj;
let {
g, h
} = obj;
let {
i,
j
} = obj;
let {
k = function() {
dosomething();
}
} = obj;
Examples of correct code for this rule with the "never"
option:
/*eslint object-curly-newline: ["error", "never"]*/
/*eslint-env es6*/
let a = {};
let b = {foo: 1};
let c = {foo: 1, bar: 2};
let d = {foo: 1,
bar: 2};
let e = {foo: function() {
dosomething();
}};
let {} = obj;
let {f} = obj;
let {g, h} = obj;
let {i,
j} = obj;
let {k = function() {
dosomething();
}} = obj;
multiline
Examples of incorrect code for this rule with the { "multiline": true }
option:
/*eslint object-curly-newline: ["error", { "multiline": true }]*/
/*eslint-env es6*/
let a = {
};
let b = {
foo: 1
};
let c = {
foo: 1, bar: 2
};
let d = {foo: 1,
bar: 2};
let e = {foo: function() {
dosomething();
}};
let {
} = obj;
let {
f
} = obj;
let {
g, h
} = obj;
let {i,
j} = obj;
let {k = function() {
dosomething();
}} = obj;
Examples of correct code for this rule with the { "multiline": true }
option:
/*eslint object-curly-newline: ["error", { "multiline": true }]*/
/*eslint-env es6*/
let a = {};
let b = {foo: 1};
let c = {foo: 1, bar: 2};
let d = {
foo: 1,
bar: 2
};
let e = {
foo: function() {
dosomething();
}
};
let {} = obj;
let {f} = obj;
let {g, h} = obj;
let {
i,
j
} = obj;
let {
k = function() {
dosomething();
}
} = obj;
minProperties
Examples of incorrect code for this rule with the { "minProperties": 2 }
option:
/*eslint object-curly-newline: ["error", { "minProperties": 2 }]*/
/*eslint-env es6*/
let a = {
};
let b = {
foo: 1
};
let c = {foo: 1, bar: 2};
let d = {foo: 1,
bar: 2};
let e = {
foo: function() {
dosomething();
}
};
let {
} = obj;
let {
f
} = obj;
let {g, h} = obj;
let {i,
j} = obj;
let {
k = function() {
dosomething();
}
} = obj;
Examples of correct code for this rule with the { "minProperties": 2 }
option:
/*eslint object-curly-newline: ["error", { "minProperties": 2 }]*/
/*eslint-env es6*/
let a = {};
let b = {foo: 1};
let c = {
foo: 1, bar: 2
};
let d = {
foo: 1,
bar: 2
};
let e = {foo: function() {
dosomething();
}};
let {} = obj;
let {f} = obj;
let {
g, h
} = obj;
let {
i,
j
} = obj;
let {k = function() {
dosomething();
}} = obj;
consistent
Examples of incorrect code for this rule with the default { "consistent": true }
option:
/*eslint object-curly-newline: ["error", { "consistent": true }]*/
/*eslint-env es6*/
let a = {foo: 1
};
let b = {
foo: 1};
let c = {foo: 1, bar: 2
};
let d = {
foo: 1, bar: 2};
let e = {foo: function() {
dosomething();
}
};
let f = {
foo: function() {
dosomething();}};
let {g
} = obj;
let {
h} = obj;
let {i, j
} = obj;
let {k, l
} = obj;
let {
m, n} = obj;
let {
o, p} = obj;
let {q = function() {
dosomething();
}
} = obj;
let {
r = function() {
dosomething();
}} = obj;
Examples of correct code for this rule with the default { "consistent": true }
option:
/*eslint object-curly-newline: ["error", { "consistent": true }]*/
/*eslint-env es6*/
let empty1 = {};
let empty2 = {
};
let a = {foo: 1};
let b = {
foo: 1
};
let c = {
foo: 1, bar: 2
};
let d = {
foo: 1,
bar: 2
};
let e = {foo: function() {dosomething();}};
let f = {
foo: function() {
dosomething();
}
};
let {} = obj;
let {
} = obj;
let {g} = obj;
let {
h
} = obj;
let {i, j} = obj;
let {
k, l
} = obj;
let {m,
n} = obj;
let {
o,
p
} = obj;
let {q = function() {dosomething();}} = obj;
let {
r = function() {
dosomething();
}
} = obj;
ObjectExpression and ObjectPattern
Examples of incorrect code for this rule with the { "ObjectExpression": "always", "ObjectPattern": "never" }
options:
/*eslint object-curly-newline: ["error", { "ObjectExpression": "always", "ObjectPattern": "never" }]*/
/*eslint-env es6*/
let a = {};
let b = {foo: 1};
let c = {foo: 1, bar: 2};
let d = {foo: 1,
bar: 2};
let e = {foo: function() {
dosomething();
}};
let {
} = obj;
let {
f
} = obj;
let {
g, h
} = obj;
let {
i,
j
} = obj;
let {
k = function() {
dosomething();
}
} = obj;
Examples of correct code for this rule with the { "ObjectExpression": "always", "ObjectPattern": "never" }
options:
/*eslint object-curly-newline: ["error", { "ObjectExpression": "always", "ObjectPattern": "never" }]*/
/*eslint-env es6*/
let a = {
};
let b = {
foo: 1
};
let c = {
foo: 1, bar: 2
};
let d = {
foo: 1,
bar: 2
};
let e = {
foo: function() {
dosomething();
}
};
let {} = obj;
let {f} = obj;
let {g, h} = obj;
let {i,
j} = obj;
let {k = function() {
dosomething();
}} = obj;
ImportDeclaration and ExportDeclaration
Examples of incorrect code for this rule with the { "ImportDeclaration": "always", "ExportDeclaration": "never" }
options:
/*eslint object-curly-newline: ["error", { "ImportDeclaration": "always", "ExportDeclaration": "never" }]*/
/*eslint-env es6*/
import {foo, bar} from 'foo-bar';
import {foo as f, bar} from 'foo-bar';
import {foo,
bar} from 'foo-bar';
export {
foo,
bar
};
export {
foo as f,
bar
} from 'foo-bar';
Examples of correct code for this rule with the { "ImportDeclaration": "always", "ExportDeclaration": "never" }
options:
/*eslint object-curly-newline: ["error", { "ImportDeclaration": "always", "ExportDeclaration": "never" }]*/
/*eslint-env es6*/
import {
foo,
bar
} from 'foo-bar';
import {
foo, bar
} from 'foo-bar';
import {
foo as f,
bar
} from 'foo-bar';
export { foo, bar } from 'foo-bar';
export { foo as f, bar } from 'foo-bar';
Compatibility
When Not To Use It
If you don't want to enforce consistent line breaks inside braces, then it's safe to disable this rule.
Related Rules
- [comma-spacing](comma-spacing.md)
- [key-spacing](key-spacing.md)
- [object-curly-spacing](object-curly-spacing.md)
- [object-property-newline](object-property-newline.md) Source: http://eslint.org/docs/rules/
["fill"] is better written in dot notation. Open
ctx.fillStyle = (colors['fill']);
- Read upRead up
- Exclude checks
Require Dot Notation (dot-notation)
In JavaScript, one can access properties using the dot notation (foo.bar
) or square-bracket notation (foo["bar"]
). However, the dot notation is often preferred because it is easier to read, less verbose, and works better with aggressive JavaScript minimizers.
foo["bar"];
Rule Details
This rule is aimed at maintaining code consistency and improving code readability by encouraging use of the dot notation style whenever possible. As such, it will warn when it encounters an unnecessary use of square-bracket notation.
Examples of incorrect code for this rule:
/*eslint dot-notation: "error"*/
var x = foo["bar"];
Examples of correct code for this rule:
/*eslint dot-notation: "error"*/
var x = foo.bar;
var x = foo[bar]; // Property name is a variable, square-bracket notation required
Options
This rule accepts a single options argument:
- Set the
allowKeywords
option tofalse
(default istrue
) to follow ECMAScript version 3 compatible style, avoiding dot notation for reserved word properties. - Set the
allowPattern
option to a regular expression string to allow bracket notation for property names that match a pattern (by default, no pattern is tested).
allowKeywords
Examples of correct code for the { "allowKeywords": false }
option:
/*eslint dot-notation: ["error", { "allowKeywords": false }]*/
var foo = { "class": "CS 101" }
var x = foo["class"]; // Property name is a reserved word, square-bracket notation required
allowPattern
For example, when preparing data to be sent to an external API, it is often required to use property names that include underscores. If the camelcase
rule is in effect, these snake case properties would not be allowed. By providing an allowPattern
to the dot-notation
rule, these snake case properties can be accessed with bracket notation.
Examples of correct code for the sample { "allowPattern": "^[a-z]+(_[a-z]+)+$" }
option:
/*eslint camelcase: "error"*/
/*eslint dot-notation: ["error", { "allowPattern": "^[a-z]+(_[a-z]+)+$" }]*/
var data = {};
data.foo_bar = 42;
var data = {};
data["fooBar"] = 42;
var data = {};
data["foo_bar"] = 42; // no warning
Source: http://eslint.org/docs/rules/
Closing curly brace does not appear on the same line as the subsequent block. Open
if (this.J.value && this.K.value) { this.masterState = 1 ^ this.slaveState; }
- Read upRead up
- Exclude checks
Require Brace Style (brace-style)
Brace style is closely related to indent style in programming and describes the placement of braces relative to their control statement and body. There are probably a dozen, if not more, brace styles in the world.
The one true brace style is one of the most common brace styles in JavaScript, in which the opening brace of a block is placed on the same line as its corresponding statement or declaration. For example:
if (foo) {
bar();
} else {
baz();
}
One common variant of one true brace style is called Stroustrup, in which the else
statements in an if-else
construct, as well as catch
and finally
, must be on its own line after the preceding closing brace. For example:
if (foo) {
bar();
}
else {
baz();
}
Another style is called Allman, in which all the braces are expected to be on their own lines without any extra indentation. For example:
if (foo)
{
bar();
}
else
{
baz();
}
While no style is considered better than the other, most developers agree that having a consistent style throughout a project is important for its long-term maintainability.
Rule Details
This rule enforces consistent brace style for blocks.
Options
This rule has a string option:
-
"1tbs"
(default) enforces one true brace style -
"stroustrup"
enforces Stroustrup style -
"allman"
enforces Allman style
This rule has an object option for an exception:
-
"allowSingleLine": true
(defaultfalse
) allows the opening and closing braces for a block to be on the same line
1tbs
Examples of incorrect code for this rule with the default "1tbs"
option:
/*eslint brace-style: "error"*/
function foo()
{
return true;
}
if (foo)
{
bar();
}
try
{
somethingRisky();
} catch(e)
{
handleError();
}
if (foo) {
bar();
}
else {
baz();
}
Examples of correct code for this rule with the default "1tbs"
option:
/*eslint brace-style: "error"*/
function foo() {
return true;
}
if (foo) {
bar();
}
if (foo) {
bar();
} else {
baz();
}
try {
somethingRisky();
} catch(e) {
handleError();
}
// when there are no braces, there are no problems
if (foo) bar();
else if (baz) boom();
Examples of correct code for this rule with the "1tbs", { "allowSingleLine": true }
options:
/*eslint brace-style: ["error", "1tbs", { "allowSingleLine": true }]*/
function nop() { return; }
if (foo) { bar(); }
if (foo) { bar(); } else { baz(); }
try { somethingRisky(); } catch(e) { handleError(); }
if (foo) { baz(); } else {
boom();
}
if (foo) { baz(); } else if (bar) {
boom();
}
if (foo) { baz(); } else
if (bar) {
boom();
}
if (foo) { baz(); } else if (bar) {
boom();
}
try { somethingRisky(); } catch(e) {
handleError();
}
stroustrup
Examples of incorrect code for this rule with the "stroustrup"
option:
/*eslint brace-style: ["error", "stroustrup"]*/
function foo()
{
return true;
}
if (foo)
{
bar();
}
try
{
somethingRisky();
} catch(e)
{
handleError();
}
if (foo) {
bar();
} else {
baz();
}
Examples of correct code for this rule with the "stroustrup"
option:
/*eslint brace-style: ["error", "stroustrup"]*/
function foo() {
return true;
}
if (foo) {
bar();
}
if (foo) {
bar();
}
else {
baz();
}
try {
somethingRisky();
}
catch(e) {
handleError();
}
// when there are no braces, there are no problems
if (foo) bar();
else if (baz) boom();
Examples of correct code for this rule with the "stroustrup", { "allowSingleLine": true }
options:
/*eslint brace-style: ["error", "stroustrup", { "allowSingleLine": true }]*/
function nop() { return; }
if (foo) { bar(); }
if (foo) { bar(); }
else { baz(); }
try { somethingRisky(); }
catch(e) { handleError(); }
allman
Examples of incorrect code for this rule with the "allman"
option:
/*eslint brace-style: ["error", "allman"]*/
function foo() {
return true;
}
if (foo)
{
bar(); }
try
{
somethingRisky();
} catch(e)
{
handleError();
}
if (foo) {
bar();
} else {
baz();
}
Examples of correct code for this rule with the "allman"
option:
/*eslint brace-style: ["error", "allman"]*/
function foo()
{
return true;
}
if (foo)
{
bar();
}
if (foo)
{
bar();
}
else
{
baz();
}
try
{
somethingRisky();
}
catch(e)
{
handleError();
}
// when there are no braces, there are no problems
if (foo) bar();
else if (baz) boom();
Examples of correct code for this rule with the "allman", { "allowSingleLine": true }
options:
/*eslint brace-style: ["error", "allman", { "allowSingleLine": true }]*/
function nop() { return; }
if (foo) { bar(); }
if (foo) { bar(); }
else { baz(); }
try { somethingRisky(); }
catch(e) { handleError(); }
When Not To Use It
If you don't want to enforce a particular brace style, don't enable this rule.
Further Reading
["input_text"] is better written in dot notation. Open
ctx.fillStyle = colors['input_text'];
- Read upRead up
- Exclude checks
Require Dot Notation (dot-notation)
In JavaScript, one can access properties using the dot notation (foo.bar
) or square-bracket notation (foo["bar"]
). However, the dot notation is often preferred because it is easier to read, less verbose, and works better with aggressive JavaScript minimizers.
foo["bar"];
Rule Details
This rule is aimed at maintaining code consistency and improving code readability by encouraging use of the dot notation style whenever possible. As such, it will warn when it encounters an unnecessary use of square-bracket notation.
Examples of incorrect code for this rule:
/*eslint dot-notation: "error"*/
var x = foo["bar"];
Examples of correct code for this rule:
/*eslint dot-notation: "error"*/
var x = foo.bar;
var x = foo[bar]; // Property name is a variable, square-bracket notation required
Options
This rule accepts a single options argument:
- Set the
allowKeywords
option tofalse
(default istrue
) to follow ECMAScript version 3 compatible style, avoiding dot notation for reserved word properties. - Set the
allowPattern
option to a regular expression string to allow bracket notation for property names that match a pattern (by default, no pattern is tested).
allowKeywords
Examples of correct code for the { "allowKeywords": false }
option:
/*eslint dot-notation: ["error", { "allowKeywords": false }]*/
var foo = { "class": "CS 101" }
var x = foo["class"]; // Property name is a reserved word, square-bracket notation required
allowPattern
For example, when preparing data to be sent to an external API, it is often required to use property names that include underscores. If the camelcase
rule is in effect, these snake case properties would not be allowed. By providing an allowPattern
to the dot-notation
rule, these snake case properties can be accessed with bracket notation.
Examples of correct code for the sample { "allowPattern": "^[a-z]+(_[a-z]+)+$" }
option:
/*eslint camelcase: "error"*/
/*eslint dot-notation: ["error", { "allowPattern": "^[a-z]+(_[a-z]+)+$" }]*/
var data = {};
data.foo_bar = 42;
var data = {};
data["fooBar"] = 42;
var data = {};
data["foo_bar"] = 42; // no warning
Source: http://eslint.org/docs/rules/
Expected a line break before this closing brace. Open
import { correctWidth, lineTo, moveTo, fillText } from '../canvasApi';
- Read upRead up
- Exclude checks
enforce consistent line breaks inside braces (object-curly-newline)
A number of style guides require or disallow line breaks inside of object braces and other tokens.
Rule Details
This rule enforces consistent line breaks inside braces of object literals or destructuring assignments.
Options
This rule has either a string option:
-
"always"
requires line breaks inside braces -
"never"
disallows line breaks inside braces
Or an object option:
-
"multiline": true
requires line breaks if there are line breaks inside properties or between properties. Otherwise, it disallows line breaks. -
"minProperties"
requires line breaks if the number of properties is at least the given integer. By default, an error will also be reported if an object contains linebreaks and has fewer properties than the given integer. However, the second behavior is disabled if theconsistent
option is set totrue
-
"consistent": true
(default) requires that either both curly braces, or neither, directly enclose newlines. Note that enabling this option will also change the behavior of theminProperties
option. (SeeminProperties
above for more information)
You can specify different options for object literals, destructuring assignments, and named imports and exports:
{
"object-curly-newline": ["error", {
"ObjectExpression": "always",
"ObjectPattern": { "multiline": true },
"ImportDeclaration": "never",
"ExportDeclaration": { "multiline": true, "minProperties": 3 }
}]
}
-
"ObjectExpression"
configuration for object literals -
"ObjectPattern"
configuration for object patterns of destructuring assignments -
"ImportDeclaration"
configuration for named imports -
"ExportDeclaration"
configuration for named exports
always
Examples of incorrect code for this rule with the "always"
option:
/*eslint object-curly-newline: ["error", "always"]*/
/*eslint-env es6*/
let a = {};
let b = {foo: 1};
let c = {foo: 1, bar: 2};
let d = {foo: 1,
bar: 2};
let e = {foo() {
dosomething();
}};
let {} = obj;
let {f} = obj;
let {g, h} = obj;
let {i,
j} = obj;
let {k = function() {
dosomething();
}} = obj;
Examples of correct code for this rule with the "always"
option:
/*eslint object-curly-newline: ["error", "always"]*/
/*eslint-env es6*/
let a = {
};
let b = {
foo: 1
};
let c = {
foo: 1, bar: 2
};
let d = {
foo: 1,
bar: 2
};
let e = {
foo: function() {
dosomething();
}
};
let {
} = obj;
let {
f
} = obj;
let {
g, h
} = obj;
let {
i,
j
} = obj;
let {
k = function() {
dosomething();
}
} = obj;
never
Examples of incorrect code for this rule with the "never"
option:
/*eslint object-curly-newline: ["error", "never"]*/
/*eslint-env es6*/
let a = {
};
let b = {
foo: 1
};
let c = {
foo: 1, bar: 2
};
let d = {
foo: 1,
bar: 2
};
let e = {
foo: function() {
dosomething();
}
};
let {
} = obj;
let {
f
} = obj;
let {
g, h
} = obj;
let {
i,
j
} = obj;
let {
k = function() {
dosomething();
}
} = obj;
Examples of correct code for this rule with the "never"
option:
/*eslint object-curly-newline: ["error", "never"]*/
/*eslint-env es6*/
let a = {};
let b = {foo: 1};
let c = {foo: 1, bar: 2};
let d = {foo: 1,
bar: 2};
let e = {foo: function() {
dosomething();
}};
let {} = obj;
let {f} = obj;
let {g, h} = obj;
let {i,
j} = obj;
let {k = function() {
dosomething();
}} = obj;
multiline
Examples of incorrect code for this rule with the { "multiline": true }
option:
/*eslint object-curly-newline: ["error", { "multiline": true }]*/
/*eslint-env es6*/
let a = {
};
let b = {
foo: 1
};
let c = {
foo: 1, bar: 2
};
let d = {foo: 1,
bar: 2};
let e = {foo: function() {
dosomething();
}};
let {
} = obj;
let {
f
} = obj;
let {
g, h
} = obj;
let {i,
j} = obj;
let {k = function() {
dosomething();
}} = obj;
Examples of correct code for this rule with the { "multiline": true }
option:
/*eslint object-curly-newline: ["error", { "multiline": true }]*/
/*eslint-env es6*/
let a = {};
let b = {foo: 1};
let c = {foo: 1, bar: 2};
let d = {
foo: 1,
bar: 2
};
let e = {
foo: function() {
dosomething();
}
};
let {} = obj;
let {f} = obj;
let {g, h} = obj;
let {
i,
j
} = obj;
let {
k = function() {
dosomething();
}
} = obj;
minProperties
Examples of incorrect code for this rule with the { "minProperties": 2 }
option:
/*eslint object-curly-newline: ["error", { "minProperties": 2 }]*/
/*eslint-env es6*/
let a = {
};
let b = {
foo: 1
};
let c = {foo: 1, bar: 2};
let d = {foo: 1,
bar: 2};
let e = {
foo: function() {
dosomething();
}
};
let {
} = obj;
let {
f
} = obj;
let {g, h} = obj;
let {i,
j} = obj;
let {
k = function() {
dosomething();
}
} = obj;
Examples of correct code for this rule with the { "minProperties": 2 }
option:
/*eslint object-curly-newline: ["error", { "minProperties": 2 }]*/
/*eslint-env es6*/
let a = {};
let b = {foo: 1};
let c = {
foo: 1, bar: 2
};
let d = {
foo: 1,
bar: 2
};
let e = {foo: function() {
dosomething();
}};
let {} = obj;
let {f} = obj;
let {
g, h
} = obj;
let {
i,
j
} = obj;
let {k = function() {
dosomething();
}} = obj;
consistent
Examples of incorrect code for this rule with the default { "consistent": true }
option:
/*eslint object-curly-newline: ["error", { "consistent": true }]*/
/*eslint-env es6*/
let a = {foo: 1
};
let b = {
foo: 1};
let c = {foo: 1, bar: 2
};
let d = {
foo: 1, bar: 2};
let e = {foo: function() {
dosomething();
}
};
let f = {
foo: function() {
dosomething();}};
let {g
} = obj;
let {
h} = obj;
let {i, j
} = obj;
let {k, l
} = obj;
let {
m, n} = obj;
let {
o, p} = obj;
let {q = function() {
dosomething();
}
} = obj;
let {
r = function() {
dosomething();
}} = obj;
Examples of correct code for this rule with the default { "consistent": true }
option:
/*eslint object-curly-newline: ["error", { "consistent": true }]*/
/*eslint-env es6*/
let empty1 = {};
let empty2 = {
};
let a = {foo: 1};
let b = {
foo: 1
};
let c = {
foo: 1, bar: 2
};
let d = {
foo: 1,
bar: 2
};
let e = {foo: function() {dosomething();}};
let f = {
foo: function() {
dosomething();
}
};
let {} = obj;
let {
} = obj;
let {g} = obj;
let {
h
} = obj;
let {i, j} = obj;
let {
k, l
} = obj;
let {m,
n} = obj;
let {
o,
p
} = obj;
let {q = function() {dosomething();}} = obj;
let {
r = function() {
dosomething();
}
} = obj;
ObjectExpression and ObjectPattern
Examples of incorrect code for this rule with the { "ObjectExpression": "always", "ObjectPattern": "never" }
options:
/*eslint object-curly-newline: ["error", { "ObjectExpression": "always", "ObjectPattern": "never" }]*/
/*eslint-env es6*/
let a = {};
let b = {foo: 1};
let c = {foo: 1, bar: 2};
let d = {foo: 1,
bar: 2};
let e = {foo: function() {
dosomething();
}};
let {
} = obj;
let {
f
} = obj;
let {
g, h
} = obj;
let {
i,
j
} = obj;
let {
k = function() {
dosomething();
}
} = obj;
Examples of correct code for this rule with the { "ObjectExpression": "always", "ObjectPattern": "never" }
options:
/*eslint object-curly-newline: ["error", { "ObjectExpression": "always", "ObjectPattern": "never" }]*/
/*eslint-env es6*/
let a = {
};
let b = {
foo: 1
};
let c = {
foo: 1, bar: 2
};
let d = {
foo: 1,
bar: 2
};
let e = {
foo: function() {
dosomething();
}
};
let {} = obj;
let {f} = obj;
let {g, h} = obj;
let {i,
j} = obj;
let {k = function() {
dosomething();
}} = obj;
ImportDeclaration and ExportDeclaration
Examples of incorrect code for this rule with the { "ImportDeclaration": "always", "ExportDeclaration": "never" }
options:
/*eslint object-curly-newline: ["error", { "ImportDeclaration": "always", "ExportDeclaration": "never" }]*/
/*eslint-env es6*/
import {foo, bar} from 'foo-bar';
import {foo as f, bar} from 'foo-bar';
import {foo,
bar} from 'foo-bar';
export {
foo,
bar
};
export {
foo as f,
bar
} from 'foo-bar';
Examples of correct code for this rule with the { "ImportDeclaration": "always", "ExportDeclaration": "never" }
options:
/*eslint object-curly-newline: ["error", { "ImportDeclaration": "always", "ExportDeclaration": "never" }]*/
/*eslint-env es6*/
import {
foo,
bar
} from 'foo-bar';
import {
foo, bar
} from 'foo-bar';
import {
foo as f,
bar
} from 'foo-bar';
export { foo, bar } from 'foo-bar';
export { foo as f, bar } from 'foo-bar';
Compatibility
When Not To Use It
If you don't want to enforce consistent line breaks inside braces, then it's safe to disable this rule.
Related Rules
- [comma-spacing](comma-spacing.md)
- [key-spacing](key-spacing.md)
- [object-curly-spacing](object-curly-spacing.md)
- [object-property-newline](object-property-newline.md) Source: http://eslint.org/docs/rules/
Unexpected use of '^'. Open
else if (this.J.value ^ this.K.value) { this.masterState = this.J.value; }
- Read upRead up
- Exclude checks
disallow bitwise operators (no-bitwise)
The use of bitwise operators in JavaScript is very rare and often &
or |
is simply a mistyped &&
or ||
, which will lead to unexpected behavior.
var x = y | z;
Rule Details
This rule disallows bitwise operators.
Examples of incorrect code for this rule:
/*eslint no-bitwise: "error"*/
var x = y | z;
var x = y & z;
var x = y ^ z;
var x = ~ z;
var x = y << z;
var x = y >> z;
var x = y >>> z;
x |= y;
x &= y;
x ^= y;
x <<= y;
x >>= y;
x >>>= y;
Examples of correct code for this rule:
/*eslint no-bitwise: "error"*/
var x = y || z;
var x = y && z;
var x = y > z;
var x = y < z;
x += y;
Options
This rule has an object option:
-
"allow"
: Allows a list of bitwise operators to be used as exceptions. -
"int32Hint"
: Allows the use of bitwise OR in|0
pattern for type casting.
allow
Examples of correct code for this rule with the { "allow": ["~"] }
option:
/*eslint no-bitwise: ["error", { "allow": ["~"] }] */
~[1,2,3].indexOf(1) === -1;
int32Hint
Examples of correct code for this rule with the { "int32Hint": true }
option:
/*eslint no-bitwise: ["error", { "int32Hint": true }] */
var b = a|0;
Source: http://eslint.org/docs/rules/
Trailing spaces not allowed. Open
var ctx = simulationArea.context;
- Read upRead up
- Exclude checks
disallow trailing whitespace at the end of lines (no-trailing-spaces)
Sometimes in the course of editing files, you can end up with extra whitespace at the end of lines. These whitespace differences can be picked up by source control systems and flagged as diffs, causing frustration for developers. While this extra whitespace causes no functional issues, many code conventions require that trailing spaces be removed before check-in.
Rule Details
This rule disallows trailing whitespace (spaces, tabs, and other Unicode whitespace characters) at the end of lines.
Examples of incorrect code for this rule:
/*eslint no-trailing-spaces: "error"*/
var foo = 0;//•••••
var baz = 5;//••
//•••••
Examples of correct code for this rule:
/*eslint no-trailing-spaces: "error"*/
var foo = 0;
var baz = 5;
Options
This rule has an object option:
-
"skipBlankLines": false
(default) disallows trailing whitespace on empty lines -
"skipBlankLines": true
allows trailing whitespace on empty lines -
"ignoreComments": false
(default) disallows trailing whitespace in comment blocks -
"ignoreComments": true
allows trailing whitespace in comment blocks
skipBlankLines
Examples of correct code for this rule with the { "skipBlankLines": true }
option:
/*eslint no-trailing-spaces: ["error", { "skipBlankLines": true }]*/
var foo = 0;
var baz = 5;
//•••••
ignoreComments
Examples of correct code for this rule with the { "ignoreComments": true }
option:
/*eslint no-trailing-spaces: ["error", { "ignoreComments": true }]*/
//foo•
//•••••
/**
*•baz
*••
*•bar
*/
Source: http://eslint.org/docs/rules/
["stroke"] is better written in dot notation. Open
ctx.strokeStyle = (colors['stroke']);
- Read upRead up
- Exclude checks
Require Dot Notation (dot-notation)
In JavaScript, one can access properties using the dot notation (foo.bar
) or square-bracket notation (foo["bar"]
). However, the dot notation is often preferred because it is easier to read, less verbose, and works better with aggressive JavaScript minimizers.
foo["bar"];
Rule Details
This rule is aimed at maintaining code consistency and improving code readability by encouraging use of the dot notation style whenever possible. As such, it will warn when it encounters an unnecessary use of square-bracket notation.
Examples of incorrect code for this rule:
/*eslint dot-notation: "error"*/
var x = foo["bar"];
Examples of correct code for this rule:
/*eslint dot-notation: "error"*/
var x = foo.bar;
var x = foo[bar]; // Property name is a variable, square-bracket notation required
Options
This rule accepts a single options argument:
- Set the
allowKeywords
option tofalse
(default istrue
) to follow ECMAScript version 3 compatible style, avoiding dot notation for reserved word properties. - Set the
allowPattern
option to a regular expression string to allow bracket notation for property names that match a pattern (by default, no pattern is tested).
allowKeywords
Examples of correct code for the { "allowKeywords": false }
option:
/*eslint dot-notation: ["error", { "allowKeywords": false }]*/
var foo = { "class": "CS 101" }
var x = foo["class"]; // Property name is a reserved word, square-bracket notation required
allowPattern
For example, when preparing data to be sent to an external API, it is often required to use property names that include underscores. If the camelcase
rule is in effect, these snake case properties would not be allowed. By providing an allowPattern
to the dot-notation
rule, these snake case properties can be accessed with bracket notation.
Examples of correct code for the sample { "allowPattern": "^[a-z]+(_[a-z]+)+$" }
option:
/*eslint camelcase: "error"*/
/*eslint dot-notation: ["error", { "allowPattern": "^[a-z]+(_[a-z]+)+$" }]*/
var data = {};
data.foo_bar = 42;
var data = {};
data["fooBar"] = 42;
var data = {};
data["foo_bar"] = 42; // no warning
Source: http://eslint.org/docs/rules/
Closing curly brace does not appear on the same line as the subsequent block. Open
if (this.J.value && this.K.value) { this.masterState = 1 ^ this.slaveState; }
- Read upRead up
- Exclude checks
Require Brace Style (brace-style)
Brace style is closely related to indent style in programming and describes the placement of braces relative to their control statement and body. There are probably a dozen, if not more, brace styles in the world.
The one true brace style is one of the most common brace styles in JavaScript, in which the opening brace of a block is placed on the same line as its corresponding statement or declaration. For example:
if (foo) {
bar();
} else {
baz();
}
One common variant of one true brace style is called Stroustrup, in which the else
statements in an if-else
construct, as well as catch
and finally
, must be on its own line after the preceding closing brace. For example:
if (foo) {
bar();
}
else {
baz();
}
Another style is called Allman, in which all the braces are expected to be on their own lines without any extra indentation. For example:
if (foo)
{
bar();
}
else
{
baz();
}
While no style is considered better than the other, most developers agree that having a consistent style throughout a project is important for its long-term maintainability.
Rule Details
This rule enforces consistent brace style for blocks.
Options
This rule has a string option:
-
"1tbs"
(default) enforces one true brace style -
"stroustrup"
enforces Stroustrup style -
"allman"
enforces Allman style
This rule has an object option for an exception:
-
"allowSingleLine": true
(defaultfalse
) allows the opening and closing braces for a block to be on the same line
1tbs
Examples of incorrect code for this rule with the default "1tbs"
option:
/*eslint brace-style: "error"*/
function foo()
{
return true;
}
if (foo)
{
bar();
}
try
{
somethingRisky();
} catch(e)
{
handleError();
}
if (foo) {
bar();
}
else {
baz();
}
Examples of correct code for this rule with the default "1tbs"
option:
/*eslint brace-style: "error"*/
function foo() {
return true;
}
if (foo) {
bar();
}
if (foo) {
bar();
} else {
baz();
}
try {
somethingRisky();
} catch(e) {
handleError();
}
// when there are no braces, there are no problems
if (foo) bar();
else if (baz) boom();
Examples of correct code for this rule with the "1tbs", { "allowSingleLine": true }
options:
/*eslint brace-style: ["error", "1tbs", { "allowSingleLine": true }]*/
function nop() { return; }
if (foo) { bar(); }
if (foo) { bar(); } else { baz(); }
try { somethingRisky(); } catch(e) { handleError(); }
if (foo) { baz(); } else {
boom();
}
if (foo) { baz(); } else if (bar) {
boom();
}
if (foo) { baz(); } else
if (bar) {
boom();
}
if (foo) { baz(); } else if (bar) {
boom();
}
try { somethingRisky(); } catch(e) {
handleError();
}
stroustrup
Examples of incorrect code for this rule with the "stroustrup"
option:
/*eslint brace-style: ["error", "stroustrup"]*/
function foo()
{
return true;
}
if (foo)
{
bar();
}
try
{
somethingRisky();
} catch(e)
{
handleError();
}
if (foo) {
bar();
} else {
baz();
}
Examples of correct code for this rule with the "stroustrup"
option:
/*eslint brace-style: ["error", "stroustrup"]*/
function foo() {
return true;
}
if (foo) {
bar();
}
if (foo) {
bar();
}
else {
baz();
}
try {
somethingRisky();
}
catch(e) {
handleError();
}
// when there are no braces, there are no problems
if (foo) bar();
else if (baz) boom();
Examples of correct code for this rule with the "stroustrup", { "allowSingleLine": true }
options:
/*eslint brace-style: ["error", "stroustrup", { "allowSingleLine": true }]*/
function nop() { return; }
if (foo) { bar(); }
if (foo) { bar(); }
else { baz(); }
try { somethingRisky(); }
catch(e) { handleError(); }
allman
Examples of incorrect code for this rule with the "allman"
option:
/*eslint brace-style: ["error", "allman"]*/
function foo() {
return true;
}
if (foo)
{
bar(); }
try
{
somethingRisky();
} catch(e)
{
handleError();
}
if (foo) {
bar();
} else {
baz();
}
Examples of correct code for this rule with the "allman"
option:
/*eslint brace-style: ["error", "allman"]*/
function foo()
{
return true;
}
if (foo)
{
bar();
}
if (foo)
{
bar();
}
else
{
baz();
}
try
{
somethingRisky();
}
catch(e)
{
handleError();
}
// when there are no braces, there are no problems
if (foo) bar();
else if (baz) boom();
Examples of correct code for this rule with the "allman", { "allowSingleLine": true }
options:
/*eslint brace-style: ["error", "allman", { "allowSingleLine": true }]*/
function nop() { return; }
if (foo) { bar(); }
if (foo) { bar(); }
else { baz(); }
try { somethingRisky(); }
catch(e) { handleError(); }
When Not To Use It
If you don't want to enforce a particular brace style, don't enable this rule.
Further Reading
Expected '!==' and instead saw '!='. Open
if (this.clockInp.value != undefined && this.J.value != undefined && this.K.value != undefined) return true;
- 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.clockInp.value == 0 && this.J.value != undefined && this.K.value != undefined) {
- 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
} else if (this.clockInp.value != undefined) {
- 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.reset.value == 1) return true;
- 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.clockInp.value == 0 && this.J.value != undefined && this.K.value != undefined) {
- 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
} else if (this.clockInp.value == 0 && this.J.value != undefined && this.K.value != undefined) {
- 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
} else if (this.en.value == 1 || this.en.connections.length == 0) {
- 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.clockInp.value == 1) {
- 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.clockInp.value == this.prevClockState) {
- 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.clockInp.value != undefined && this.J.value != undefined && this.K.value != undefined) return true;
- 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
} else if (this.clockInp.value == 0 && this.J.value != undefined && this.K.value != undefined) {
- 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
} else if (this.clockInp.value == 0 && this.J.value != undefined && this.K.value != undefined) {
- 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
} else if (this.en.value == 0) {
- 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.clockInp.value == 0 && this.J.value != undefined && this.K.value != undefined) {
- 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.clockInp.value != undefined && this.J.value != undefined && this.K.value != undefined) return true;
- 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.reset.value == 1) {
- 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
} else if (this.en.value == 1 || this.en.connections.length == 0) {
- 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.qOutput.value != this.slaveState) {
- 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/
Similar blocks of code found in 2 locations. Consider refactoring. Open
customDraw() {
var ctx = simulationArea.context;
ctx.strokeStyle = (colors['stroke']);
ctx.fillStyle = (colors['fill']);
ctx.beginPath();
- Read upRead up
Duplicated Code
Duplicated code can lead to software that is hard to understand and difficult to change. The Don't Repeat Yourself (DRY) principle states:
Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.
When you violate DRY, bugs and maintenance problems are sure to follow. Duplicated code has a tendency to both continue to replicate and also to diverge (leaving bugs as two similar implementations differ in subtle ways).
Tuning
This issue has a mass of 251.
We set useful threshold defaults for the languages we support but you may want to adjust these settings based on your project guidelines.
The threshold configuration represents the minimum mass a code block must have to be analyzed for duplication. The lower the threshold, the more fine-grained the comparison.
If the engine is too easily reporting duplication, try raising the threshold. If you suspect that the engine isn't catching enough duplication, try lowering the threshold. The best setting tends to differ from language to language.
See codeclimate-duplication
's documentation for more information about tuning the mass threshold in your .codeclimate.yml
.
Refactorings
- Extract Method
- Extract Class
- Form Template Method
- Introduce Null Object
- Pull Up Method
- Pull Up Field
- Substitute Algorithm
Further Reading
- Don't Repeat Yourself on the C2 Wiki
- Duplicated Code on SourceMaking
- Refactoring: Improving the Design of Existing Code by Martin Fowler. Duplicated Code, p76
Identical blocks of code found in 2 locations. Consider refactoring. Open
if (this.clockInp.value == 0 && this.J.value != undefined && this.K.value != undefined) {
if (this.J.value && this.K.value) { this.masterState = 1 ^ this.slaveState; }
else if (this.J.value ^ this.K.value) { this.masterState = this.J.value; }
}
- Read upRead up
Duplicated Code
Duplicated code can lead to software that is hard to understand and difficult to change. The Don't Repeat Yourself (DRY) principle states:
Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.
When you violate DRY, bugs and maintenance problems are sure to follow. Duplicated code has a tendency to both continue to replicate and also to diverge (leaving bugs as two similar implementations differ in subtle ways).
Tuning
This issue has a mass of 144.
We set useful threshold defaults for the languages we support but you may want to adjust these settings based on your project guidelines.
The threshold configuration represents the minimum mass a code block must have to be analyzed for duplication. The lower the threshold, the more fine-grained the comparison.
If the engine is too easily reporting duplication, try raising the threshold. If you suspect that the engine isn't catching enough duplication, try lowering the threshold. The best setting tends to differ from language to language.
See codeclimate-duplication
's documentation for more information about tuning the mass threshold in your .codeclimate.yml
.
Refactorings
- Extract Method
- Extract Class
- Form Template Method
- Introduce Null Object
- Pull Up Method
- Pull Up Field
- Substitute Algorithm
Further Reading
- Don't Repeat Yourself on the C2 Wiki
- Duplicated Code on SourceMaking
- Refactoring: Improving the Design of Existing Code by Martin Fowler. Duplicated Code, p76
Identical blocks of code found in 2 locations. Consider refactoring. Open
} else if (this.clockInp.value == 0 && this.J.value != undefined && this.K.value != undefined) {
if (this.J.value && this.K.value) { this.masterState = 1 ^ this.slaveState; }
else if (this.J.value ^ this.K.value) { this.masterState = this.J.value; }
}
- Read upRead up
Duplicated Code
Duplicated code can lead to software that is hard to understand and difficult to change. The Don't Repeat Yourself (DRY) principle states:
Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.
When you violate DRY, bugs and maintenance problems are sure to follow. Duplicated code has a tendency to both continue to replicate and also to diverge (leaving bugs as two similar implementations differ in subtle ways).
Tuning
This issue has a mass of 144.
We set useful threshold defaults for the languages we support but you may want to adjust these settings based on your project guidelines.
The threshold configuration represents the minimum mass a code block must have to be analyzed for duplication. The lower the threshold, the more fine-grained the comparison.
If the engine is too easily reporting duplication, try raising the threshold. If you suspect that the engine isn't catching enough duplication, try lowering the threshold. The best setting tends to differ from language to language.
See codeclimate-duplication
's documentation for more information about tuning the mass threshold in your .codeclimate.yml
.
Refactorings
- Extract Method
- Extract Class
- Form Template Method
- Introduce Null Object
- Pull Up Method
- Pull Up Field
- Substitute Algorithm
Further Reading
- Don't Repeat Yourself on the C2 Wiki
- Duplicated Code on SourceMaking
- Refactoring: Improving the Design of Existing Code by Martin Fowler. Duplicated Code, p76
Similar blocks of code found in 2 locations. Consider refactoring. Open
nodes: {
J: findNode(this.J),
K: findNode(this.K),
clockInp: findNode(this.clockInp),
qOutput: findNode(this.qOutput),
- Read upRead up
Duplicated Code
Duplicated code can lead to software that is hard to understand and difficult to change. The Don't Repeat Yourself (DRY) principle states:
Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.
When you violate DRY, bugs and maintenance problems are sure to follow. Duplicated code has a tendency to both continue to replicate and also to diverge (leaving bugs as two similar implementations differ in subtle ways).
Tuning
This issue has a mass of 110.
We set useful threshold defaults for the languages we support but you may want to adjust these settings based on your project guidelines.
The threshold configuration represents the minimum mass a code block must have to be analyzed for duplication. The lower the threshold, the more fine-grained the comparison.
If the engine is too easily reporting duplication, try raising the threshold. If you suspect that the engine isn't catching enough duplication, try lowering the threshold. The best setting tends to differ from language to language.
See codeclimate-duplication
's documentation for more information about tuning the mass threshold in your .codeclimate.yml
.
Refactorings
- Extract Method
- Extract Class
- Form Template Method
- Introduce Null Object
- Pull Up Method
- Pull Up Field
- Substitute Algorithm
Further Reading
- Don't Repeat Yourself on the C2 Wiki
- Duplicated Code on SourceMaking
- Refactoring: Improving the Design of Existing Code by Martin Fowler. Duplicated Code, p76
Similar blocks of code found in 5 locations. Consider refactoring. Open
if (this.qOutput.value != this.slaveState) {
this.qOutput.value = this.slaveState;
this.qInvOutput.value = this.flipBits(this.slaveState);
simulationArea.simulationQueue.add(this.qOutput);
simulationArea.simulationQueue.add(this.qInvOutput);
- Read upRead up
Duplicated Code
Duplicated code can lead to software that is hard to understand and difficult to change. The Don't Repeat Yourself (DRY) principle states:
Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.
When you violate DRY, bugs and maintenance problems are sure to follow. Duplicated code has a tendency to both continue to replicate and also to diverge (leaving bugs as two similar implementations differ in subtle ways).
Tuning
This issue has a mass of 107.
We set useful threshold defaults for the languages we support but you may want to adjust these settings based on your project guidelines.
The threshold configuration represents the minimum mass a code block must have to be analyzed for duplication. The lower the threshold, the more fine-grained the comparison.
If the engine is too easily reporting duplication, try raising the threshold. If you suspect that the engine isn't catching enough duplication, try lowering the threshold. The best setting tends to differ from language to language.
See codeclimate-duplication
's documentation for more information about tuning the mass threshold in your .codeclimate.yml
.
Refactorings
- Extract Method
- Extract Class
- Form Template Method
- Introduce Null Object
- Pull Up Method
- Pull Up Field
- Substitute Algorithm
Further Reading
- Don't Repeat Yourself on the C2 Wiki
- Duplicated Code on SourceMaking
- Refactoring: Improving the Design of Existing Code by Martin Fowler. Duplicated Code, p76
Similar blocks of code found in 3 locations. Consider refactoring. Open
newBitWidth(bitWidth) {
this.bitWidth = bitWidth;
this.dInp.bitWidth = bitWidth;
this.qOutput.bitWidth = bitWidth;
this.qInvOutput.bitWidth = bitWidth;
- Read upRead up
Duplicated Code
Duplicated code can lead to software that is hard to understand and difficult to change. The Don't Repeat Yourself (DRY) principle states:
Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.
When you violate DRY, bugs and maintenance problems are sure to follow. Duplicated code has a tendency to both continue to replicate and also to diverge (leaving bugs as two similar implementations differ in subtle ways).
Tuning
This issue has a mass of 82.
We set useful threshold defaults for the languages we support but you may want to adjust these settings based on your project guidelines.
The threshold configuration represents the minimum mass a code block must have to be analyzed for duplication. The lower the threshold, the more fine-grained the comparison.
If the engine is too easily reporting duplication, try raising the threshold. If you suspect that the engine isn't catching enough duplication, try lowering the threshold. The best setting tends to differ from language to language.
See codeclimate-duplication
's documentation for more information about tuning the mass threshold in your .codeclimate.yml
.
Refactorings
- Extract Method
- Extract Class
- Form Template Method
- Introduce Null Object
- Pull Up Method
- Pull Up Field
- Substitute Algorithm
Further Reading
- Don't Repeat Yourself on the C2 Wiki
- Duplicated Code on SourceMaking
- Refactoring: Improving the Design of Existing Code by Martin Fowler. Duplicated Code, p76
Similar blocks of code found in 2 locations. Consider refactoring. Open
if (this.clockInp.value != undefined && this.J.value != undefined && this.K.value != undefined) return true;
- Read upRead up
Duplicated Code
Duplicated code can lead to software that is hard to understand and difficult to change. The Don't Repeat Yourself (DRY) principle states:
Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.
When you violate DRY, bugs and maintenance problems are sure to follow. Duplicated code has a tendency to both continue to replicate and also to diverge (leaving bugs as two similar implementations differ in subtle ways).
Tuning
This issue has a mass of 45.
We set useful threshold defaults for the languages we support but you may want to adjust these settings based on your project guidelines.
The threshold configuration represents the minimum mass a code block must have to be analyzed for duplication. The lower the threshold, the more fine-grained the comparison.
If the engine is too easily reporting duplication, try raising the threshold. If you suspect that the engine isn't catching enough duplication, try lowering the threshold. The best setting tends to differ from language to language.
See codeclimate-duplication
's documentation for more information about tuning the mass threshold in your .codeclimate.yml
.
Refactorings
- Extract Method
- Extract Class
- Form Template Method
- Introduce Null Object
- Pull Up Method
- Pull Up Field
- Substitute Algorithm
Further Reading
- Don't Repeat Yourself on the C2 Wiki
- Duplicated Code on SourceMaking
- Refactoring: Improving the Design of Existing Code by Martin Fowler. Duplicated Code, p76
Expected 1 empty line after import statement not followed by another import. Open
import { colors } from '../themer/themer';
- Read upRead up
- Exclude checks
For more information visit Source: http://eslint.org/docs/rules/