Showing 494 of 494 total issues
Rule doesn't have all its properties in alphabetical order. Open
.sst-lime,.sst-hover-lime:hover{
- Exclude checks
Use of !important Open
background-color:#009688!important
- Exclude checks
Rule doesn't have all its properties in alphabetical order. Open
.sst-black,.sst-hover-black:hover{
- Exclude checks
Use of !important Open
color:#000!important;
- Exclude checks
Use of !important Open
color:#00ffff!important
- Exclude checks
Use of !important Open
color:#e91e63!important
- Exclude checks
Use of !important Open
color:#673ab7!important
- Exclude checks
Use of !important Open
border-color:#4CAF50!important
- Exclude checks
Missing standard property 'transform' to go along with '-webkit-transform'. Open
-webkit-transform:scale(1)
- Exclude checks
Use of !important Open
background-color:transparent!important
- Exclude checks
Rule doesn't have all its properties in alphabetical order. Open
.sst-brown,.sst-hover-brown:hover{
- Exclude checks
Rule doesn't have all its properties in alphabetical order. Open
.sst-indigo,.sst-hover-indigo:hover{
- Exclude checks
Rule doesn't have all its properties in alphabetical order. Open
.sst-teal,.sst-hover-teal:hover{
- Exclude checks
Use of !important Open
color:#2196F3!important
- Exclude checks
Use of !important Open
border-color:#e91e63!important
- Exclude checks
Expected '===' and instead saw '=='. Open
if(rawFile.status == 200 || rawFile.status == 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 (typeof onload == "function") {
- 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/
Spaces are hard to count. Use {2}. Open
wpmType = Math.round(((document.JobOp.typed.value.replace(/ /g, " ").split(" ").length) / totalTime) * 60)
- Read upRead up
- Exclude checks
disallow multiple spaces in regular expression literals (no-regex-spaces)
Regular expressions can be very complex and difficult to understand, which is why it's important to keep them as simple as possible in order to avoid mistakes. One of the more error-prone things you can do with a regular expression is to use more than one space, such as:
var re = /foo bar/;
In this regular expression, it's very hard to tell how many spaces are intended to be matched. It's better to use only one space and then specify how many spaces are expected, such as:
var re = /foo {3}bar/;
Now it is very clear that three spaces are expected to be matched.
Rule Details
This rule disallows multiple spaces in regular expression literals.
Examples of incorrect code for this rule:
/*eslint no-regex-spaces: "error"*/
var re = /foo bar/;
var re = new RegExp("foo bar");
Examples of correct code for this rule:
/*eslint no-regex-spaces: "error"*/
var re = /foo {3}bar/;
var re = new RegExp("foo {3}bar");
When Not To Use It
If you want to allow multiple spaces in a regular expression, then you can safely turn this rule off.
Related Rules
- [no-div-regex](no-div-regex.md)
- [no-control-regex](no-control-regex.md) Source: http://eslint.org/docs/rules/
Spaces are hard to count. Use {2}. Open
var thisTyped = document.JobOp.typed.value.replace(/ /g, " ");
- Read upRead up
- Exclude checks
disallow multiple spaces in regular expression literals (no-regex-spaces)
Regular expressions can be very complex and difficult to understand, which is why it's important to keep them as simple as possible in order to avoid mistakes. One of the more error-prone things you can do with a regular expression is to use more than one space, such as:
var re = /foo bar/;
In this regular expression, it's very hard to tell how many spaces are intended to be matched. It's better to use only one space and then specify how many spaces are expected, such as:
var re = /foo {3}bar/;
Now it is very clear that three spaces are expected to be matched.
Rule Details
This rule disallows multiple spaces in regular expression literals.
Examples of incorrect code for this rule:
/*eslint no-regex-spaces: "error"*/
var re = /foo bar/;
var re = new RegExp("foo bar");
Examples of correct code for this rule:
/*eslint no-regex-spaces: "error"*/
var re = /foo {3}bar/;
var re = new RegExp("foo {3}bar");
When Not To Use It
If you want to allow multiple spaces in a regular expression, then you can safely turn this rule off.
Related Rules
- [no-div-regex](no-div-regex.md)
- [no-control-regex](no-control-regex.md) Source: http://eslint.org/docs/rules/
Use of !important Open
border-color:#f1f1f1!important
- Exclude checks