Showing 119 of 119 total issues
include
is used at the top level. Use inside class
or module
. Open
include LooseLeaf::TaskHelpers
- Read upRead up
- Exclude checks
This cop checks that include
, extend
and prepend
exists at
the top level.
Using these at the top level affects the behavior of Object
.
There will not be using include
, extend
and prepend
at
the top level. Let's use it inside class
or module
.
Example:
# bad
include M
class C
end
# bad
extend M
class C
end
# bad
prepend M
class C
end
# good
class C
include M
end
# good
class C
extend M
end
# good
class C
prepend M
end
Block must not be padded by blank lines. Open
export default class Cable {
- Read upRead up
- Exclude checks
require or disallow padding within blocks (padded-blocks)
Some style guides require block statements to start and end with blank lines. The goal is to improve readability by visually separating the block content and the surrounding code.
if (a) {
b();
}
Since it's good to have a consistent code style, you should either always write padded blocks or never do it.
Rule Details
This rule enforces consistent empty line padding within blocks.
Options
This rule has one option, which can be a string option or an object option.
String option:
-
"always"
(default) requires empty lines at the beginning and ending of block statements (exceptswitch
statements and classes) -
"never"
disallows empty lines at the beginning and ending of block statements (exceptswitch
statements and classes)
Object option:
-
"blocks"
require or disallow padding within block statements -
"classes"
require or disallow padding within classes -
"switches"
require or disallow padding withinswitch
statements
always
Examples of incorrect code for this rule with the default "always"
option:
/*eslint padded-blocks: ["error", "always"]*/
if (a) {
b();
}
if (a) { b(); }
if (a)
{
b();
}
if (a) {
b();
}
if (a) {
b();
}
if (a) {
// comment
b();
}
Examples of correct code for this rule with the default "always"
option:
/*eslint padded-blocks: ["error", "always"]*/
if (a) {
b();
}
if (a)
{
b();
}
if (a) {
// comment
b();
}
never
Examples of incorrect code for this rule with the "never"
option:
/*eslint padded-blocks: ["error", "never"]*/
if (a) {
b();
}
if (a)
{
b();
}
if (a) {
b();
}
if (a) {
b();
}
Examples of correct code for this rule with the "never"
option:
/*eslint padded-blocks: ["error", "never"]*/
if (a) {
b();
}
if (a)
{
b();
}
blocks
Examples of incorrect code for this rule with the { "blocks": "always" }
option:
/*eslint padded-blocks: ["error", { "blocks": "always" }]*/
if (a) {
b();
}
if (a) { b(); }
if (a)
{
b();
}
if (a) {
b();
}
if (a) {
b();
}
if (a) {
// comment
b();
}
Examples of correct code for this rule with the { "blocks": "always" }
option:
/*eslint padded-blocks: ["error", { "blocks": "always" }]*/
if (a) {
b();
}
if (a)
{
b();
}
if (a) {
// comment
b();
}
Examples of incorrect code for this rule with the { "blocks": "never" }
option:
/*eslint padded-blocks: ["error", { "blocks": "never" }]*/
if (a) {
b();
}
if (a)
{
b();
}
if (a) {
b();
}
if (a) {
b();
}
Examples of correct code for this rule with the { "blocks": "never" }
option:
/*eslint padded-blocks: ["error", { "blocks": "never" }]*/
if (a) {
b();
}
if (a)
{
b();
}
classes
Examples of incorrect code for this rule with the { "classes": "always" }
option:
/*eslint padded-blocks: ["error", { "classes": "always" }]*/
class A {
constructor(){
}
}
Examples of correct code for this rule with the { "classes": "always" }
option:
/*eslint padded-blocks: ["error", { "classes": "always" }]*/
class A {
constructor(){
}
}
Examples of incorrect code for this rule with the { "classes": "never" }
option:
/*eslint padded-blocks: ["error", { "classes": "never" }]*/
class A {
constructor(){
}
}
Examples of correct code for this rule with the { "classes": "never" }
option:
/*eslint padded-blocks: ["error", { "classes": "never" }]*/
class A {
constructor(){
}
}
switches
Examples of incorrect code for this rule with the { "switches": "always" }
option:
/*eslint padded-blocks: ["error", { "switches": "always" }]*/
switch (a) {
case 0: foo();
}
Examples of correct code for this rule with the { "switches": "always" }
option:
/*eslint padded-blocks: ["error", { "switches": "always" }]*/
switch (a) {
case 0: foo();
}
if (a) {
b();
}
Examples of incorrect code for this rule with the { "switches": "never" }
option:
/*eslint padded-blocks: ["error", { "switches": "never" }]*/
switch (a) {
case 0: foo();
}
Examples of correct code for this rule with the { "switches": "never" }
option:
/*eslint padded-blocks: ["error", { "switches": "never" }]*/
switch (a) {
case 0: foo();
}
if (a) {
b();
}
When Not To Use It
You can turn this rule off if you are not concerned with the consistency of padding within blocks. Source: http://eslint.org/docs/rules/
Block must not be padded by blank lines. Open
class CollaborativeAttribute {
- Read upRead up
- Exclude checks
require or disallow padding within blocks (padded-blocks)
Some style guides require block statements to start and end with blank lines. The goal is to improve readability by visually separating the block content and the surrounding code.
if (a) {
b();
}
Since it's good to have a consistent code style, you should either always write padded blocks or never do it.
Rule Details
This rule enforces consistent empty line padding within blocks.
Options
This rule has one option, which can be a string option or an object option.
String option:
-
"always"
(default) requires empty lines at the beginning and ending of block statements (exceptswitch
statements and classes) -
"never"
disallows empty lines at the beginning and ending of block statements (exceptswitch
statements and classes)
Object option:
-
"blocks"
require or disallow padding within block statements -
"classes"
require or disallow padding within classes -
"switches"
require or disallow padding withinswitch
statements
always
Examples of incorrect code for this rule with the default "always"
option:
/*eslint padded-blocks: ["error", "always"]*/
if (a) {
b();
}
if (a) { b(); }
if (a)
{
b();
}
if (a) {
b();
}
if (a) {
b();
}
if (a) {
// comment
b();
}
Examples of correct code for this rule with the default "always"
option:
/*eslint padded-blocks: ["error", "always"]*/
if (a) {
b();
}
if (a)
{
b();
}
if (a) {
// comment
b();
}
never
Examples of incorrect code for this rule with the "never"
option:
/*eslint padded-blocks: ["error", "never"]*/
if (a) {
b();
}
if (a)
{
b();
}
if (a) {
b();
}
if (a) {
b();
}
Examples of correct code for this rule with the "never"
option:
/*eslint padded-blocks: ["error", "never"]*/
if (a) {
b();
}
if (a)
{
b();
}
blocks
Examples of incorrect code for this rule with the { "blocks": "always" }
option:
/*eslint padded-blocks: ["error", { "blocks": "always" }]*/
if (a) {
b();
}
if (a) { b(); }
if (a)
{
b();
}
if (a) {
b();
}
if (a) {
b();
}
if (a) {
// comment
b();
}
Examples of correct code for this rule with the { "blocks": "always" }
option:
/*eslint padded-blocks: ["error", { "blocks": "always" }]*/
if (a) {
b();
}
if (a)
{
b();
}
if (a) {
// comment
b();
}
Examples of incorrect code for this rule with the { "blocks": "never" }
option:
/*eslint padded-blocks: ["error", { "blocks": "never" }]*/
if (a) {
b();
}
if (a)
{
b();
}
if (a) {
b();
}
if (a) {
b();
}
Examples of correct code for this rule with the { "blocks": "never" }
option:
/*eslint padded-blocks: ["error", { "blocks": "never" }]*/
if (a) {
b();
}
if (a)
{
b();
}
classes
Examples of incorrect code for this rule with the { "classes": "always" }
option:
/*eslint padded-blocks: ["error", { "classes": "always" }]*/
class A {
constructor(){
}
}
Examples of correct code for this rule with the { "classes": "always" }
option:
/*eslint padded-blocks: ["error", { "classes": "always" }]*/
class A {
constructor(){
}
}
Examples of incorrect code for this rule with the { "classes": "never" }
option:
/*eslint padded-blocks: ["error", { "classes": "never" }]*/
class A {
constructor(){
}
}
Examples of correct code for this rule with the { "classes": "never" }
option:
/*eslint padded-blocks: ["error", { "classes": "never" }]*/
class A {
constructor(){
}
}
switches
Examples of incorrect code for this rule with the { "switches": "always" }
option:
/*eslint padded-blocks: ["error", { "switches": "always" }]*/
switch (a) {
case 0: foo();
}
Examples of correct code for this rule with the { "switches": "always" }
option:
/*eslint padded-blocks: ["error", { "switches": "always" }]*/
switch (a) {
case 0: foo();
}
if (a) {
b();
}
Examples of incorrect code for this rule with the { "switches": "never" }
option:
/*eslint padded-blocks: ["error", { "switches": "never" }]*/
switch (a) {
case 0: foo();
}
Examples of correct code for this rule with the { "switches": "never" }
option:
/*eslint padded-blocks: ["error", { "switches": "never" }]*/
switch (a) {
case 0: foo();
}
if (a) {
b();
}
When Not To Use It
You can turn this rule off if you are not concerned with the consistency of padding within blocks. Source: http://eslint.org/docs/rules/
Block must not be padded by blank lines. Open
export default class Events {
- Read upRead up
- Exclude checks
require or disallow padding within blocks (padded-blocks)
Some style guides require block statements to start and end with blank lines. The goal is to improve readability by visually separating the block content and the surrounding code.
if (a) {
b();
}
Since it's good to have a consistent code style, you should either always write padded blocks or never do it.
Rule Details
This rule enforces consistent empty line padding within blocks.
Options
This rule has one option, which can be a string option or an object option.
String option:
-
"always"
(default) requires empty lines at the beginning and ending of block statements (exceptswitch
statements and classes) -
"never"
disallows empty lines at the beginning and ending of block statements (exceptswitch
statements and classes)
Object option:
-
"blocks"
require or disallow padding within block statements -
"classes"
require or disallow padding within classes -
"switches"
require or disallow padding withinswitch
statements
always
Examples of incorrect code for this rule with the default "always"
option:
/*eslint padded-blocks: ["error", "always"]*/
if (a) {
b();
}
if (a) { b(); }
if (a)
{
b();
}
if (a) {
b();
}
if (a) {
b();
}
if (a) {
// comment
b();
}
Examples of correct code for this rule with the default "always"
option:
/*eslint padded-blocks: ["error", "always"]*/
if (a) {
b();
}
if (a)
{
b();
}
if (a) {
// comment
b();
}
never
Examples of incorrect code for this rule with the "never"
option:
/*eslint padded-blocks: ["error", "never"]*/
if (a) {
b();
}
if (a)
{
b();
}
if (a) {
b();
}
if (a) {
b();
}
Examples of correct code for this rule with the "never"
option:
/*eslint padded-blocks: ["error", "never"]*/
if (a) {
b();
}
if (a)
{
b();
}
blocks
Examples of incorrect code for this rule with the { "blocks": "always" }
option:
/*eslint padded-blocks: ["error", { "blocks": "always" }]*/
if (a) {
b();
}
if (a) { b(); }
if (a)
{
b();
}
if (a) {
b();
}
if (a) {
b();
}
if (a) {
// comment
b();
}
Examples of correct code for this rule with the { "blocks": "always" }
option:
/*eslint padded-blocks: ["error", { "blocks": "always" }]*/
if (a) {
b();
}
if (a)
{
b();
}
if (a) {
// comment
b();
}
Examples of incorrect code for this rule with the { "blocks": "never" }
option:
/*eslint padded-blocks: ["error", { "blocks": "never" }]*/
if (a) {
b();
}
if (a)
{
b();
}
if (a) {
b();
}
if (a) {
b();
}
Examples of correct code for this rule with the { "blocks": "never" }
option:
/*eslint padded-blocks: ["error", { "blocks": "never" }]*/
if (a) {
b();
}
if (a)
{
b();
}
classes
Examples of incorrect code for this rule with the { "classes": "always" }
option:
/*eslint padded-blocks: ["error", { "classes": "always" }]*/
class A {
constructor(){
}
}
Examples of correct code for this rule with the { "classes": "always" }
option:
/*eslint padded-blocks: ["error", { "classes": "always" }]*/
class A {
constructor(){
}
}
Examples of incorrect code for this rule with the { "classes": "never" }
option:
/*eslint padded-blocks: ["error", { "classes": "never" }]*/
class A {
constructor(){
}
}
Examples of correct code for this rule with the { "classes": "never" }
option:
/*eslint padded-blocks: ["error", { "classes": "never" }]*/
class A {
constructor(){
}
}
switches
Examples of incorrect code for this rule with the { "switches": "always" }
option:
/*eslint padded-blocks: ["error", { "switches": "always" }]*/
switch (a) {
case 0: foo();
}
Examples of correct code for this rule with the { "switches": "always" }
option:
/*eslint padded-blocks: ["error", { "switches": "always" }]*/
switch (a) {
case 0: foo();
}
if (a) {
b();
}
Examples of incorrect code for this rule with the { "switches": "never" }
option:
/*eslint padded-blocks: ["error", { "switches": "never" }]*/
switch (a) {
case 0: foo();
}
Examples of correct code for this rule with the { "switches": "never" }
option:
/*eslint padded-blocks: ["error", { "switches": "never" }]*/
switch (a) {
case 0: foo();
}
if (a) {
b();
}
When Not To Use It
You can turn this rule off if you are not concerned with the consistency of padding within blocks. Source: http://eslint.org/docs/rules/
Empty line detected around arguments. Open
2nd argument: Perform a dry run by passing 'true' as a second argument.
- Read upRead up
- Exclude checks
This cops checks if empty lines exist around the arguments of a method invocation.
Example:
# bad
do_something(
foo
)
process(bar,
baz: qux,
thud: fred)
some_method(
[1,2,3],
x: y
)
# good
do_something(
foo
)
process(bar,
baz: qux,
thud: fred)
some_method(
[1,2,3],
x: y
)
Too many blank lines at the end of file. Max of 0 allowed. Open
- Read upRead up
- Exclude checks
disallow multiple empty lines (no-multiple-empty-lines)
Some developers prefer to have multiple blank lines removed, while others feel that it helps improve readability. Whitespace is useful for separating logical sections of code, but excess whitespace takes up more of the screen.
Rule Details
This rule aims to reduce the scrolling required when reading through your code. It will warn when the maximum amount of empty lines has been exceeded.
Options
This rule has an object option:
-
"max"
(default:2
) enforces a maximum number of consecutive empty lines. -
"maxEOF"
enforces a maximum number of consecutive empty lines at the end of files. -
"maxBOF"
enforces a maximum number of consecutive empty lines at the beginning of files.
max
Examples of incorrect code for this rule with the default { "max": 2 }
option:
/*eslint no-multiple-empty-lines: "error"*/
var foo = 5;
var bar = 3;
Examples of correct code for this rule with the default { "max": 2 }
option:
/*eslint no-multiple-empty-lines: "error"*/
var foo = 5;
var bar = 3;
maxEOF
Examples of incorrect code for this rule with the { max: 2, maxEOF: 1 }
options:
/*eslint no-multiple-empty-lines: ["error", { "max": 2, "maxEOF": 1 }]*/
var foo = 5;
var bar = 3;
Examples of correct code for this rule with the { max: 2, maxEOF: 1 }
options:
/*eslint no-multiple-empty-lines: ["error", { "max": 2, "maxEOF": 1 }]*/
var foo = 5;
var bar = 3;
maxBOF
Examples of incorrect code for this rule with the { max: 2, maxBOF: 1 }
options:
/*eslint no-multiple-empty-lines: ["error", { "max": 2, "maxBOF": 1 }]*/
var foo = 5;
var bar = 3;
Examples of correct code for this rule with the { max: 2, maxBOF: 1 }
options:
/*eslint no-multiple-empty-lines: ["error", { "max": 2, "maxBOF": 1}]*/
var foo = 5;
var bar = 3;
When Not To Use It
If you do not care about extra blank lines, turn this off. Source: http://eslint.org/docs/rules/
Too many blank lines at the end of file. Max of 0 allowed. Open
- Read upRead up
- Exclude checks
disallow multiple empty lines (no-multiple-empty-lines)
Some developers prefer to have multiple blank lines removed, while others feel that it helps improve readability. Whitespace is useful for separating logical sections of code, but excess whitespace takes up more of the screen.
Rule Details
This rule aims to reduce the scrolling required when reading through your code. It will warn when the maximum amount of empty lines has been exceeded.
Options
This rule has an object option:
-
"max"
(default:2
) enforces a maximum number of consecutive empty lines. -
"maxEOF"
enforces a maximum number of consecutive empty lines at the end of files. -
"maxBOF"
enforces a maximum number of consecutive empty lines at the beginning of files.
max
Examples of incorrect code for this rule with the default { "max": 2 }
option:
/*eslint no-multiple-empty-lines: "error"*/
var foo = 5;
var bar = 3;
Examples of correct code for this rule with the default { "max": 2 }
option:
/*eslint no-multiple-empty-lines: "error"*/
var foo = 5;
var bar = 3;
maxEOF
Examples of incorrect code for this rule with the { max: 2, maxEOF: 1 }
options:
/*eslint no-multiple-empty-lines: ["error", { "max": 2, "maxEOF": 1 }]*/
var foo = 5;
var bar = 3;
Examples of correct code for this rule with the { max: 2, maxEOF: 1 }
options:
/*eslint no-multiple-empty-lines: ["error", { "max": 2, "maxEOF": 1 }]*/
var foo = 5;
var bar = 3;
maxBOF
Examples of incorrect code for this rule with the { max: 2, maxBOF: 1 }
options:
/*eslint no-multiple-empty-lines: ["error", { "max": 2, "maxBOF": 1 }]*/
var foo = 5;
var bar = 3;
Examples of correct code for this rule with the { max: 2, maxBOF: 1 }
options:
/*eslint no-multiple-empty-lines: ["error", { "max": 2, "maxBOF": 1}]*/
var foo = 5;
var bar = 3;
When Not To Use It
If you do not care about extra blank lines, turn this off. Source: http://eslint.org/docs/rules/
Avoid when
branches without a body. Open
when 'minor'
- Read upRead up
- Exclude checks
This cop checks for the presence of when
branches without a body.
Example:
# bad
case foo
when bar then 1
when baz then # nothing
end
Example:
# good
case foo
when bar then 1
when baz then 2
end
Expected '===' and instead saw '=='. Open
if (NODE_ENV == 'prod') {
- 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/
include
is used at the top level. Use inside class
or module
. Open
include LooseLeaf::TaskHelpers
- Read upRead up
- Exclude checks
This cop checks that include
, extend
and prepend
exists at
the top level.
Using these at the top level affects the behavior of Object
.
There will not be using include
, extend
and prepend
at
the top level. Let's use it inside class
or module
.
Example:
# bad
include M
class C
end
# bad
extend M
class C
end
# bad
prepend M
class C
end
# good
class C
include M
end
# good
class C
extend M
end
# good
class C
prepend M
end
Avoid when
branches without a body. Open
when 'major'
- Read upRead up
- Exclude checks
This cop checks for the presence of when
branches without a body.
Example:
# bad
case foo
when bar then 1
when baz then # nothing
end
Example:
# good
case foo
when bar then 1
when baz then 2
end
Use %i
or %I
for an array of symbols. Open
task lint: [:standardjs, :flow, :rubocop] do
- Read upRead up
- Exclude checks
This cop can check for array literals made up of symbols that are not using the %i() syntax.
Alternatively, it checks for symbol arrays using the %i() syntax on projects which do not want to use that syntax.
Configuration option: MinSize
If set, arrays with fewer elements than this value will not trigger the
cop. For example, a MinSize of
3` will not enforce a style on an array
of 2 or fewer elements.
Example: EnforcedStyle: percent (default)
# good
%i[foo bar baz]
# bad
[:foo, :bar, :baz]
Example: EnforcedStyle: brackets
# good
[:foo, :bar, :baz]
# bad
%i[foo bar baz]
Read-only global 'process' should not be modified. Open
process = require('process')
- Read upRead up
- Exclude checks
Disallow assignment to native objects or read-only global variables (no-global-assign)
JavaScript environments contain a number of built-in global variables, such as window
in browsers and process
in Node.js. In almost all cases, you don't want to assign a value to these global variables as doing so could result in losing access to important functionality. For example, you probably don't want to do this in browser code:
window = {};
While examples such as window
are obvious, there are often hundreds of built-in global objects provided by JavaScript environments. It can be hard to know if you're assigning to a global variable or not.
Rule Details
This rule disallows modifications to read-only global variables.
ESLint has the capability to configure global variables as read-only.
- [Specifying Environments](../user-guide/configuring#specifying-environments)
- [Specifying Globals](../user-guide/configuring#specifying-globals)
Examples of incorrect code for this rule:
/*eslint no-global-assign: "error"*/
Object = null
undefined = 1
/*eslint no-global-assign: "error"*/
/*eslint-env browser*/
window = {}
length = 1
top = 1
/*eslint no-global-assign: "error"*/
/*globals a:false*/
a = 1
Examples of correct code for this rule:
/*eslint no-global-assign: "error"*/
a = 1
var b = 1
b = 2
/*eslint no-global-assign: "error"*/
/*eslint-env browser*/
onload = function() {}
/*eslint no-global-assign: "error"*/
/*globals a:true*/
a = 1
Options
This rule accepts an exceptions
option, which can be used to specify a list of builtins for which reassignments will be allowed:
{
"rules": {
"no-global-assign": ["error", {"exceptions": ["Object"]}]
}
}
When Not To Use It
If you are trying to override one of the native objects.
Related Rules
- [no-extend-native](no-extend-native.md)
- [no-redeclare](no-redeclare.md)
- [no-shadow](no-shadow.md) Source: http://eslint.org/docs/rules/
Too many blank lines at the end of file. Max of 0 allowed. Open
- Read upRead up
- Exclude checks
disallow multiple empty lines (no-multiple-empty-lines)
Some developers prefer to have multiple blank lines removed, while others feel that it helps improve readability. Whitespace is useful for separating logical sections of code, but excess whitespace takes up more of the screen.
Rule Details
This rule aims to reduce the scrolling required when reading through your code. It will warn when the maximum amount of empty lines has been exceeded.
Options
This rule has an object option:
-
"max"
(default:2
) enforces a maximum number of consecutive empty lines. -
"maxEOF"
enforces a maximum number of consecutive empty lines at the end of files. -
"maxBOF"
enforces a maximum number of consecutive empty lines at the beginning of files.
max
Examples of incorrect code for this rule with the default { "max": 2 }
option:
/*eslint no-multiple-empty-lines: "error"*/
var foo = 5;
var bar = 3;
Examples of correct code for this rule with the default { "max": 2 }
option:
/*eslint no-multiple-empty-lines: "error"*/
var foo = 5;
var bar = 3;
maxEOF
Examples of incorrect code for this rule with the { max: 2, maxEOF: 1 }
options:
/*eslint no-multiple-empty-lines: ["error", { "max": 2, "maxEOF": 1 }]*/
var foo = 5;
var bar = 3;
Examples of correct code for this rule with the { max: 2, maxEOF: 1 }
options:
/*eslint no-multiple-empty-lines: ["error", { "max": 2, "maxEOF": 1 }]*/
var foo = 5;
var bar = 3;
maxBOF
Examples of incorrect code for this rule with the { max: 2, maxBOF: 1 }
options:
/*eslint no-multiple-empty-lines: ["error", { "max": 2, "maxBOF": 1 }]*/
var foo = 5;
var bar = 3;
Examples of correct code for this rule with the { max: 2, maxBOF: 1 }
options:
/*eslint no-multiple-empty-lines: ["error", { "max": 2, "maxBOF": 1}]*/
var foo = 5;
var bar = 3;
When Not To Use It
If you do not care about extra blank lines, turn this off. Source: http://eslint.org/docs/rules/
Block must not be padded by blank lines. Open
export default class TextAreaAdapter {
- Read upRead up
- Exclude checks
require or disallow padding within blocks (padded-blocks)
Some style guides require block statements to start and end with blank lines. The goal is to improve readability by visually separating the block content and the surrounding code.
if (a) {
b();
}
Since it's good to have a consistent code style, you should either always write padded blocks or never do it.
Rule Details
This rule enforces consistent empty line padding within blocks.
Options
This rule has one option, which can be a string option or an object option.
String option:
-
"always"
(default) requires empty lines at the beginning and ending of block statements (exceptswitch
statements and classes) -
"never"
disallows empty lines at the beginning and ending of block statements (exceptswitch
statements and classes)
Object option:
-
"blocks"
require or disallow padding within block statements -
"classes"
require or disallow padding within classes -
"switches"
require or disallow padding withinswitch
statements
always
Examples of incorrect code for this rule with the default "always"
option:
/*eslint padded-blocks: ["error", "always"]*/
if (a) {
b();
}
if (a) { b(); }
if (a)
{
b();
}
if (a) {
b();
}
if (a) {
b();
}
if (a) {
// comment
b();
}
Examples of correct code for this rule with the default "always"
option:
/*eslint padded-blocks: ["error", "always"]*/
if (a) {
b();
}
if (a)
{
b();
}
if (a) {
// comment
b();
}
never
Examples of incorrect code for this rule with the "never"
option:
/*eslint padded-blocks: ["error", "never"]*/
if (a) {
b();
}
if (a)
{
b();
}
if (a) {
b();
}
if (a) {
b();
}
Examples of correct code for this rule with the "never"
option:
/*eslint padded-blocks: ["error", "never"]*/
if (a) {
b();
}
if (a)
{
b();
}
blocks
Examples of incorrect code for this rule with the { "blocks": "always" }
option:
/*eslint padded-blocks: ["error", { "blocks": "always" }]*/
if (a) {
b();
}
if (a) { b(); }
if (a)
{
b();
}
if (a) {
b();
}
if (a) {
b();
}
if (a) {
// comment
b();
}
Examples of correct code for this rule with the { "blocks": "always" }
option:
/*eslint padded-blocks: ["error", { "blocks": "always" }]*/
if (a) {
b();
}
if (a)
{
b();
}
if (a) {
// comment
b();
}
Examples of incorrect code for this rule with the { "blocks": "never" }
option:
/*eslint padded-blocks: ["error", { "blocks": "never" }]*/
if (a) {
b();
}
if (a)
{
b();
}
if (a) {
b();
}
if (a) {
b();
}
Examples of correct code for this rule with the { "blocks": "never" }
option:
/*eslint padded-blocks: ["error", { "blocks": "never" }]*/
if (a) {
b();
}
if (a)
{
b();
}
classes
Examples of incorrect code for this rule with the { "classes": "always" }
option:
/*eslint padded-blocks: ["error", { "classes": "always" }]*/
class A {
constructor(){
}
}
Examples of correct code for this rule with the { "classes": "always" }
option:
/*eslint padded-blocks: ["error", { "classes": "always" }]*/
class A {
constructor(){
}
}
Examples of incorrect code for this rule with the { "classes": "never" }
option:
/*eslint padded-blocks: ["error", { "classes": "never" }]*/
class A {
constructor(){
}
}
Examples of correct code for this rule with the { "classes": "never" }
option:
/*eslint padded-blocks: ["error", { "classes": "never" }]*/
class A {
constructor(){
}
}
switches
Examples of incorrect code for this rule with the { "switches": "always" }
option:
/*eslint padded-blocks: ["error", { "switches": "always" }]*/
switch (a) {
case 0: foo();
}
Examples of correct code for this rule with the { "switches": "always" }
option:
/*eslint padded-blocks: ["error", { "switches": "always" }]*/
switch (a) {
case 0: foo();
}
if (a) {
b();
}
Examples of incorrect code for this rule with the { "switches": "never" }
option:
/*eslint padded-blocks: ["error", { "switches": "never" }]*/
switch (a) {
case 0: foo();
}
Examples of correct code for this rule with the { "switches": "never" }
option:
/*eslint padded-blocks: ["error", { "switches": "never" }]*/
switch (a) {
case 0: foo();
}
if (a) {
b();
}
When Not To Use It
You can turn this rule off if you are not concerned with the consistency of padding within blocks. Source: http://eslint.org/docs/rules/
Expected '===' and instead saw '=='. Open
if (NODE_ENV == 'prod') {
- Read upRead up
- Exclude checks
Require === and !== (eqeqeq)
It is considered good practice to use the type-safe equality operators ===
and !==
instead of their regular counterparts ==
and !=
.
The reason for this is that ==
and !=
do type coercion which follows the rather obscure Abstract Equality Comparison Algorithm.
For instance, the following statements are all considered true
:
[] == false
[] == ![]
3 == "03"
If one of those occurs in an innocent-looking statement such as a == b
the actual problem is very difficult to spot.
Rule Details
This rule is aimed at eliminating the type-unsafe equality operators.
Examples of incorrect code for this rule:
/*eslint eqeqeq: "error"*/
if (x == 42) { }
if ("" == text) { }
if (obj.getStuff() != undefined) { }
The --fix
option on the command line automatically fixes some problems reported by this rule. A problem is only fixed if one of the operands is a typeof
expression, or if both operands are literals with the same type.
Options
always
The "always"
option (default) enforces the use of ===
and !==
in every situation (except when you opt-in to more specific handling of null
[see below]).
Examples of incorrect code for the "always"
option:
/*eslint eqeqeq: ["error", "always"]*/
a == b
foo == true
bananas != 1
value == undefined
typeof foo == 'undefined'
'hello' != 'world'
0 == 0
true == true
foo == null
Examples of correct code for the "always"
option:
/*eslint eqeqeq: ["error", "always"]*/
a === b
foo === true
bananas !== 1
value === undefined
typeof foo === 'undefined'
'hello' !== 'world'
0 === 0
true === true
foo === null
This rule optionally takes a second argument, which should be an object with the following supported properties:
-
"null"
: Customize how this rule treatsnull
literals. Possible values:-
always
(default) - Always use === or !==. -
never
- Never use === or !== withnull
. -
ignore
- Do not apply this rule tonull
.
-
smart
The "smart"
option enforces the use of ===
and !==
except for these cases:
- Comparing two literal values
- Evaluating the value of
typeof
- Comparing against
null
Examples of incorrect code for the "smart"
option:
/*eslint eqeqeq: ["error", "smart"]*/
// comparing two variables requires ===
a == b
// only one side is a literal
foo == true
bananas != 1
// comparing to undefined requires ===
value == undefined
Examples of correct code for the "smart"
option:
/*eslint eqeqeq: ["error", "smart"]*/
typeof foo == 'undefined'
'hello' != 'world'
0 == 0
true == true
foo == null
allow-null
Deprecated: Instead of using this option use "always" and pass a "null" option property with value "ignore". This will tell eslint to always enforce strict equality except when comparing with the null
literal.
["error", "always", {"null": "ignore"}]
When Not To Use It
If you don't want to enforce a style for using equality operators, then it's safe to disable this rule. Source: http://eslint.org/docs/rules/
Unexpected literal in error position of callback. Open
callback(...args)
- Read upRead up
- Exclude checks
For more information visit Source: http://eslint.org/docs/rules/
Use %i
or %I
for an array of symbols. Open
task default: [:spec, :lint]
- Read upRead up
- Exclude checks
This cop can check for array literals made up of symbols that are not using the %i() syntax.
Alternatively, it checks for symbol arrays using the %i() syntax on projects which do not want to use that syntax.
Configuration option: MinSize
If set, arrays with fewer elements than this value will not trigger the
cop. For example, a MinSize of
3` will not enforce a style on an array
of 2 or fewer elements.
Example: EnforcedStyle: percent (default)
# good
%i[foo bar baz]
# bad
[:foo, :bar, :baz]
Example: EnforcedStyle: brackets
# good
[:foo, :bar, :baz]
# bad
%i[foo bar baz]
Favor modifier unless
usage when having a single-line body. Another good alternative is the usage of control flow &&
/||
. Open
unless client_version > version
- Read upRead up
- Exclude checks
Checks for if and unless statements that would fit on one line
if written as a modifier if/unless. The maximum line length is
configured in the Metrics/LineLength
cop.
Example:
# bad
if condition
do_stuff(bar)
end
unless qux.empty?
Foo.do_something
end
# good
do_stuff(bar) if condition
Foo.do_something unless qux.empty?