Showing 196 of 196 total issues
Identical blocks of code found in 7 locations. Consider refactoring. Open
require(['jquery'], function ($) {
$(document).ready(function () {
console.log('requirejs ready to use')
})
})
- 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 47.
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 7 locations. Consider refactoring. Open
require(['jquery'], function ($) {
$(document).ready(function () {
console.log('requirejs ready to use')
})
})
- 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 47.
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
Function read_helpers
has a Cognitive Complexity of 7 (exceeds 5 allowed). Consider refactoring. Open
helper_handler.prototype.read_helpers = function () {
return new Promise(function (resolve, reject) {
glob([flat_helpers_PATH, PROJECT_HELPERS_PATH], function (err, files) {
if (err) { return console.log(err) }
async.each(files, function (file, callback) {
- 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
Function file_exists
has a Cognitive Complexity of 7 (exceeds 5 allowed). Consider refactoring. Open
flat_helpers.prototype.file_exists = function (file_path) {
return new Promise(function (resolve, reject) {
fs.stat(file_path, (err, stat) => {
if (err) {
reject()
- 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
Function globalize
has a Cognitive Complexity of 7 (exceeds 5 allowed). Consider refactoring. Open
function globalize (context, root_context) {
// can't globalizer if context is not an object(string, true/false)
if (typeof context != 'object') {
return
- 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
Function register
has a Cognitive Complexity of 7 (exceeds 5 allowed). Consider refactoring. Open
helper.prototype.register = function () {
enduro.templating_engine.registerHelper('switch', function () {
// create a list out of arguments
- 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
Function deep_abstract
has a Cognitive Complexity of 7 (exceeds 5 allowed). Consider refactoring. Open
function deep_abstract (context) {
let abstraction_list = []
for (c in context) {
- 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
Function scaffold
has a Cognitive Complexity of 7 (exceeds 5 allowed). Consider refactoring. Open
scaffolder.prototype.scaffold = function (project_name, scaffolding_name) {
return new Promise(function (resolve, reject) {
if (!project_name) {
return reject({ message: 'missing project name' })
- 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
Function log
has a Cognitive Complexity of 6 (exceeds 5 allowed). Consider refactoring. Open
logger.prototype.log = function (message, newline, logtag) {
if (typeof newline === 'string') {
logtag = newline
newline = false
}
- 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
Function register
has a Cognitive Complexity of 6 (exceeds 5 allowed). Consider refactoring. Open
helper.prototype.register = function () {
enduro.templating_engine.registerHelper('partial', function (name, context, options) {
if (!options) {
- 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
Function deep_markdown
has a Cognitive Complexity of 6 (exceeds 5 allowed). Consider refactoring. Open
function deep_markdown (object) {
for (o in object) {
if (typeof object[o] === 'object') {
deep_markdown(object[o])
}
- 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
Function add_sibling_to_type
has a Cognitive Complexity of 6 (exceeds 5 allowed). Consider refactoring. Open
context_modifiers.prototype.add_sibling_to_type = function (context, type_to_search_for, added_termination, value) {
const self = this
for (key in context) {
- 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
Function dir_exists
has a Cognitive Complexity of 6 (exceeds 5 allowed). Consider refactoring. Open
flat_helpers.prototype.dir_exists = function (path_to_folder) {
return new Promise(function (resolve, reject) {
fs.stat(path_to_folder, function (err, stats) {
if (err) {
reject()
- 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
Newline required at end of file but not found. Open
}
- Read upRead up
- Exclude checks
Require file to end with single newline (eol-last)
(fixable) The --fix
option on the [command line](../user-guide/command-line-interface#fix) automatically fixes problems reported by this rule.
Trailing newlines in non-empty files are a common UNIX idiom. Benefits of trailing newlines include the ability to concatenate or append to files as well as output files to the terminal without interfering with shell prompts.
Rule Details
This rule requires at least one newline at the end of non-empty files.
Prior to v0.16.0 this rule also enforced that there was only a single line at
the end of the file. If you still want this behaviour, consider enabling
[no-multiple-empty-lines](no-multiple-empty-lines.md) with maxEOF
and/or
[no-trailing-spaces](no-trailing-spaces.md).
Examples of incorrect code for this rule:
/*eslint eol-last: "error"*/
function doSmth() {
var foo = 2;
}
Examples of correct code for this rule:
/*eslint eol-last: "error"*/
function doSmth() {
var foo = 2;
}
Options
This rule has a string option:
-
"unix"
(default) enforces line feed (LF) as newline -
"windows"
enforces carriage return line feed (CRLF) as newline Source: http://eslint.org/docs/rules/
Unexpected labeled statement. Open
company_name: 'something'
- Read upRead up
- Exclude checks
Disallow Labeled Statements (no-labels)
Labeled statements in JavaScript are used in conjunction with break
and continue
to control flow around multiple loops. For example:
outer:
while (true) {
while (true) {
break outer;
}
}
The break outer
statement ensures that this code will not result in an infinite loop because control is returned to the next statement after the outer
label was applied. If this statement was changed to be just break
, control would flow back to the outer while
statement and an infinite loop would result.
While convenient in some cases, labels tend to be used only rarely and are frowned upon by some as a remedial form of flow control that is more error prone and harder to understand.
Rule Details
This rule aims to eliminate the use of labeled statements in JavaScript. It will warn whenever a labeled statement is encountered and whenever break
or continue
are used with a label.
Examples of incorrect code for this rule:
/*eslint no-labels: "error"*/
label:
while(true) {
// ...
}
label:
while(true) {
break label;
}
label:
while(true) {
continue label;
}
label:
switch (a) {
case 0:
break label;
}
label:
{
break label;
}
label:
if (a) {
break label;
}
Examples of correct code for this rule:
/*eslint no-labels: "error"*/
var f = {
label: "foo"
};
while (true) {
break;
}
while (true) {
continue;
}
Options
The options allow labels with loop or switch statements:
-
"allowLoop"
(boolean
, default isfalse
) - If this option was settrue
, this rule ignores labels which are sticking to loop statements. -
"allowSwitch"
(boolean
, default isfalse
) - If this option was settrue
, this rule ignores labels which are sticking to switch statements.
Actually labeled statements in JavaScript can be used with other than loop and switch statements. However, this way is ultra rare, not well-known, so this would be confusing developers.
allowLoop
Examples of correct code for the { "allowLoop": true } option:
/*eslint no-labels: ["error", { "allowLoop": true }]*/
label:
while (true) {
break label;
}
allowSwitch
Examples of correct code for the { "allowSwitch": true } option:
/*eslint no-labels: ["error", { "allowSwitch": true }]*/
label:
switch (a) {
case 0:
break label;
}
When Not To Use It
If you need to use labeled statements everywhere, then you can safely disable this rule.
Related Rules
- [no-extra-label](./no-extra-label.md)
- [no-label-var](./no-label-var.md)
- [no-unused-labels](./no-unused-labels.md) Source: http://eslint.org/docs/rules/
Parsing error: Unexpected token : Open
superlative: "nice",
- Read upRead up
- Exclude checks
For more information visit Source: http://eslint.org/docs/rules/
'path' is defined but never used Open
const path = require('path')
- Read upRead up
- Exclude checks
Disallow Unused Variables (no-unused-vars)
Variables that are declared and not used anywhere in the code are most likely an error due to incomplete refactoring. Such variables take up space in the code and can lead to confusion by readers.
Rule Details
This rule is aimed at eliminating unused variables, functions, and parameters of functions.
A variable is considered to be used if any of the following are true:
- It represents a function that is called (
doSomething()
) - It is read (
var y = x
) - It is passed into a function as an argument (
doSomething(x)
)
A variable is not considered to be used if it is only ever assigned to (var x = 5
) or declared.
Examples of incorrect code for this rule:
/*eslint no-unused-vars: "error"*/
/*global some_unused_var*/
//It checks variables you have defined as global
some_unused_var = 42;
var x;
var y = 10;
y = 5;
// By default, unused arguments cause warnings.
(function(foo) {
return 5;
})();
// Unused recursive functions also cause warnings.
function fact(n) {
if (n < 2) return 1;
return n * fact(n - 1);
}
Examples of correct code for this rule:
/*eslint no-unused-vars: "error"*/
var x = 10;
alert(x);
// foo is considered used here
myFunc(function foo() {
// ...
}.bind(this));
(function(foo) {
return foo;
})();
exported
In environments outside of CommonJS or ECMAScript modules, you may use var
to create a global variable that may be used by other scripts. You can use the /* exported variableName */
comment block to indicate that this variable is being exported and therefore should not be considered unused.
Note that /* exported */
has no effect for any of the following:
- when the environment is
node
orcommonjs
- when
parserOptions.sourceType
ismodule
- when
ecmaFeatures.globalReturn
istrue
Options
This rule takes one argument which can be a string or an object. The string settings are the same as those of the vars
property (explained below).
By default this rule is enabled with all
option for variables and after-used
for arguments.
{
"rules": {
"no-unused-vars": ["error", { "vars": "all", "args": "after-used" }]
}
}
vars
The vars
option has two settings:
-
all
checks all variables for usage, including those in the global scope. This is the default setting. -
local
checks only that locally-declared variables are used but will allow global variables to be unused.
vars: local
Examples of correct code for the { "vars": "local" }
option:
/*eslint no-unused-vars: ["error", { "vars": "local" }]*/
/*global some_unused_var */
some_unused_var = 42;
varsIgnorePattern
The varsIgnorePattern
option specifies exceptions not to check for usage: variables whose names match a regexp pattern. For example, variables whose names contain ignored
or Ignored
.
Examples of correct code for the { "varsIgnorePattern": "[iI]gnored" }
option:
/*eslint no-unused-vars: ["error", { "varsIgnorePattern": "[iI]gnored" }]*/
var firstVarIgnored = 1;
var secondVar = 2;
console.log(secondVar);
args
The args
option has three settings:
-
after-used
- only the last argument must be used. This allows you, for instance, to have two named parameters to a function and as long as you use the second argument, ESLint will not warn you about the first. This is the default setting. -
all
- all named arguments must be used. -
none
- do not check arguments.
args: after-used
Examples of incorrect code for the default { "args": "after-used" }
option:
/*eslint no-unused-vars: ["error", { "args": "after-used" }]*/
// 1 error
// "baz" is defined but never used
(function(foo, bar, baz) {
return bar;
})();
Examples of correct code for the default { "args": "after-used" }
option:
/*eslint no-unused-vars: ["error", {"args": "after-used"}]*/
(function(foo, bar, baz) {
return baz;
})();
args: all
Examples of incorrect code for the { "args": "all" }
option:
/*eslint no-unused-vars: ["error", { "args": "all" }]*/
// 2 errors
// "foo" is defined but never used
// "baz" is defined but never used
(function(foo, bar, baz) {
return bar;
})();
args: none
Examples of correct code for the { "args": "none" }
option:
/*eslint no-unused-vars: ["error", { "args": "none" }]*/
(function(foo, bar, baz) {
return bar;
})();
argsIgnorePattern
The argsIgnorePattern
option specifies exceptions not to check for usage: arguments whose names match a regexp pattern. For example, variables whose names begin with an underscore.
Examples of correct code for the { "argsIgnorePattern": "^_" }
option:
/*eslint no-unused-vars: ["error", { "argsIgnorePattern": "^_" }]*/
function foo(x, _y) {
return x + 1;
}
foo();
caughtErrors
The caughtErrors
option is used for catch
block arguments validation.
It has two settings:
-
none
- do not check error objects. This is the default setting. -
all
- all named arguments must be used.
caughtErrors: none
Not specifying this rule is equivalent of assigning it to none
.
Examples of correct code for the { "caughtErrors": "none" }
option:
/*eslint no-unused-vars: ["error", { "caughtErrors": "none" }]*/
try {
//...
} catch (err) {
console.error("errors");
}
caughtErrors: all
Examples of incorrect code for the { "caughtErrors": "all" }
option:
/*eslint no-unused-vars: ["error", { "caughtErrors": "all" }]*/
// 1 error
// "err" is defined but never used
try {
//...
} catch (err) {
console.error("errors");
}
caughtErrorsIgnorePattern
The caughtErrorsIgnorePattern
option specifies exceptions not to check for usage: catch arguments whose names match a regexp pattern. For example, variables whose names begin with a string 'ignore'.
Examples of correct code for the { "caughtErrorsIgnorePattern": "^ignore" }
option:
/*eslint no-unused-vars: ["error", { "caughtErrorsIgnorePattern": "^ignore" }]*/
try {
//...
} catch (ignoreErr) {
console.error("errors");
}
When Not To Use It
If you don't want to be notified about unused variables or function arguments, you can safely turn this rule off. Source: http://eslint.org/docs/rules/
Trailing spaces not allowed. Open
//
- Read upRead up
- Exclude checks
Disallow trailing spaces at the end of lines (no-trailing-spaces)
(fixable) The --fix
option on the [command line](../user-guide/command-line-interface#fix) automatically fixes problems reported by this rule.
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 checkin.
Rule Details
The following patterns are considered problems:
/*eslint no-trailing-spaces: "error"*/
// spaces, tabs and unicode whitespaces
// are not allowed at the end of lines
var foo = 0;//•••••
var baz = 5;//••
The following patterns are not considered problems:
/*eslint no-trailing-spaces: "error"*/
var foo = 0;
var baz = 5;
Options
There is one option for this rule, skipBlankLines
. When set to true, the rule will not flag any lines that are made up purely of whitespace. In short, if a line is zero-length after being trimmed of whitespace, then the rule will not flag that line when skipBlankLines
is enabled.
You can enable this option in your config like this:
{
"no-trailing-spaces": ["error", { "skipBlankLines": true }]
}
With this option enabled, The following patterns are not considered problems:
/*eslint no-trailing-spaces: ["error", { "skipBlankLines": true }]*/
var foo = 0;
//••••
var baz = 5;
Source: http://eslint.org/docs/rules/
Trailing spaces not allowed. Open
- Read upRead up
- Exclude checks
Disallow trailing spaces at the end of lines (no-trailing-spaces)
(fixable) The --fix
option on the [command line](../user-guide/command-line-interface#fix) automatically fixes problems reported by this rule.
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 checkin.
Rule Details
The following patterns are considered problems:
/*eslint no-trailing-spaces: "error"*/
// spaces, tabs and unicode whitespaces
// are not allowed at the end of lines
var foo = 0;//•••••
var baz = 5;//••
The following patterns are not considered problems:
/*eslint no-trailing-spaces: "error"*/
var foo = 0;
var baz = 5;
Options
There is one option for this rule, skipBlankLines
. When set to true, the rule will not flag any lines that are made up purely of whitespace. In short, if a line is zero-length after being trimmed of whitespace, then the rule will not flag that line when skipBlankLines
is enabled.
You can enable this option in your config like this:
{
"no-trailing-spaces": ["error", { "skipBlankLines": true }]
}
With this option enabled, The following patterns are not considered problems:
/*eslint no-trailing-spaces: ["error", { "skipBlankLines": true }]*/
var foo = 0;
//••••
var baz = 5;
Source: http://eslint.org/docs/rules/
Unexpected labeled statement. Open
this_is_visible_to_all_pages: 'under global.this_is_visible_to_all_pages'
- Read upRead up
- Exclude checks
Disallow Labeled Statements (no-labels)
Labeled statements in JavaScript are used in conjunction with break
and continue
to control flow around multiple loops. For example:
outer:
while (true) {
while (true) {
break outer;
}
}
The break outer
statement ensures that this code will not result in an infinite loop because control is returned to the next statement after the outer
label was applied. If this statement was changed to be just break
, control would flow back to the outer while
statement and an infinite loop would result.
While convenient in some cases, labels tend to be used only rarely and are frowned upon by some as a remedial form of flow control that is more error prone and harder to understand.
Rule Details
This rule aims to eliminate the use of labeled statements in JavaScript. It will warn whenever a labeled statement is encountered and whenever break
or continue
are used with a label.
Examples of incorrect code for this rule:
/*eslint no-labels: "error"*/
label:
while(true) {
// ...
}
label:
while(true) {
break label;
}
label:
while(true) {
continue label;
}
label:
switch (a) {
case 0:
break label;
}
label:
{
break label;
}
label:
if (a) {
break label;
}
Examples of correct code for this rule:
/*eslint no-labels: "error"*/
var f = {
label: "foo"
};
while (true) {
break;
}
while (true) {
continue;
}
Options
The options allow labels with loop or switch statements:
-
"allowLoop"
(boolean
, default isfalse
) - If this option was settrue
, this rule ignores labels which are sticking to loop statements. -
"allowSwitch"
(boolean
, default isfalse
) - If this option was settrue
, this rule ignores labels which are sticking to switch statements.
Actually labeled statements in JavaScript can be used with other than loop and switch statements. However, this way is ultra rare, not well-known, so this would be confusing developers.
allowLoop
Examples of correct code for the { "allowLoop": true } option:
/*eslint no-labels: ["error", { "allowLoop": true }]*/
label:
while (true) {
break label;
}
allowSwitch
Examples of correct code for the { "allowSwitch": true } option:
/*eslint no-labels: ["error", { "allowSwitch": true }]*/
label:
switch (a) {
case 0:
break label;
}
When Not To Use It
If you need to use labeled statements everywhere, then you can safely disable this rule.
Related Rules
- [no-extra-label](./no-extra-label.md)
- [no-label-var](./no-label-var.md)
- [no-unused-labels](./no-unused-labels.md) Source: http://eslint.org/docs/rules/