Function render
has 117 lines of code (exceeds 25 allowed). Consider refactoring. Invalid
render() {
const { colors, margin, size, data, year, until } = this.props
let fitleredDataByYear
if (year !== 2 && year !== 5 && year !== 10) {
Function render
has a Cognitive Complexity of 22 (exceeds 5 allowed). Consider refactoring. Invalid
render() {
const { colors, margin, size, data, year, until } = this.props
let fitleredDataByYear
if (year !== 2 && year !== 5 && year !== 10) {
- 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
The body of a for-in should be wrapped in an if statement to filter unwanted properties from the prototype. Invalid
for (const i in Array.from(keys)) {
- Read upRead up
- Exclude checks
Require Guarding for-in (guard-for-in)
Looping over objects with a for in
loop will include properties that are inherited through the prototype chain. This behavior can lead to unexpected items in your for loop.
for (key in foo) {
doSomething(key);
}
Note that simply checking foo.hasOwnProperty(key)
is likely to cause an error in some cases; see [no-prototype-builtins](no-prototype-builtins.md).
Rule Details
This rule is aimed at preventing unexpected behavior that could arise from using a for in
loop without filtering the results in the loop. As such, it will warn when for in
loops do not filter their results with an if
statement.
Examples of incorrect code for this rule:
/*eslint guard-for-in: "error"*/
for (key in foo) {
doSomething(key);
}
Examples of correct code for this rule:
/*eslint guard-for-in: "error"*/
for (key in foo) {
if (Object.prototype.hasOwnProperty.call(foo, key)) {
doSomething(key);
}
if ({}.hasOwnProperty.call(foo, key)) {
doSomething(key);
}
}
Related Rules
- [no-prototype-builtins](no-prototype-builtins.md)
Further Reading
The body of a for-in should be wrapped in an if statement to filter unwanted properties from the prototype. Invalid
for (const i in fitleredDataByYear) {
- Read upRead up
- Exclude checks
Require Guarding for-in (guard-for-in)
Looping over objects with a for in
loop will include properties that are inherited through the prototype chain. This behavior can lead to unexpected items in your for loop.
for (key in foo) {
doSomething(key);
}
Note that simply checking foo.hasOwnProperty(key)
is likely to cause an error in some cases; see [no-prototype-builtins](no-prototype-builtins.md).
Rule Details
This rule is aimed at preventing unexpected behavior that could arise from using a for in
loop without filtering the results in the loop. As such, it will warn when for in
loops do not filter their results with an if
statement.
Examples of incorrect code for this rule:
/*eslint guard-for-in: "error"*/
for (key in foo) {
doSomething(key);
}
Examples of correct code for this rule:
/*eslint guard-for-in: "error"*/
for (key in foo) {
if (Object.prototype.hasOwnProperty.call(foo, key)) {
doSomething(key);
}
if ({}.hasOwnProperty.call(foo, key)) {
doSomething(key);
}
}
Related Rules
- [no-prototype-builtins](no-prototype-builtins.md)
Further Reading
for..in loops iterate over the entire prototype chain, which is virtually never what you want. Use Object.{keys,values,entries}, and iterate over the resulting array. Invalid
for (const d in fitleredDataByYear) {
- Read upRead up
- Exclude checks
disallow specified syntax (no-restricted-syntax)
JavaScript has a lot of language features, and not everyone likes all of them. As a result, some projects choose to disallow the use of certain language features altogether. For instance, you might decide to disallow the use of try-catch
or class
, or you might decide to disallow the use of the in
operator.
Rather than creating separate rules for every language feature you want to turn off, this rule allows you to configure the syntax elements you want to restrict use of. These elements are represented by their ESTree node types. For example, a function declaration is represented by FunctionDeclaration
and the with
statement is represented by WithStatement
. You may find the full list of AST node names you can use on GitHub and use the online parser to see what type of nodes your code consists of.
You can also specify [AST selectors](../developer-guide/selectors) to restrict, allowing much more precise control over syntax patterns.
Rule Details
This rule disallows specified (that is, user-defined) syntax.
Options
This rule takes a list of strings, where each string is an AST selector:
{
"rules": {
"no-restricted-syntax": ["error", "FunctionExpression", "WithStatement", "BinaryExpression[operator='in']"]
}
}
Alternatively, the rule also accepts objects, where the selector and an optional custom message are specified:
{
"rules": {
"no-restricted-syntax": [
"error",
{
"selector": "FunctionExpression",
"message": "Function expressions are not allowed."
},
{
"selector": "CallExpression[callee.name='setTimeout'][arguments.length!=2]",
"message": "setTimeout must always be invoked with two arguments."
}
]
}
}
If a custom message is specified with the message
property, ESLint will use that message when reporting occurrences of the syntax specified in the selector
property.
The string and object formats can be freely mixed in the configuration as needed.
Examples of incorrect code for this rule with the "FunctionExpression", "WithStatement", BinaryExpression[operator='in']
options:
/* eslint no-restricted-syntax: ["error", "FunctionExpression", "WithStatement", "BinaryExpression[operator='in']"] */
with (me) {
dontMess();
}
var doSomething = function () {};
foo in bar;
Examples of correct code for this rule with the "FunctionExpression", "WithStatement", BinaryExpression[operator='in']
options:
/* eslint no-restricted-syntax: ["error", "FunctionExpression", "WithStatement", "BinaryExpression[operator='in']"] */
me.dontMess();
function doSomething() {};
foo instanceof bar;
When Not To Use It
If you don't want to restrict your code from using any JavaScript features or syntax, you should not use this rule.
Related Rules
- [no-alert](no-alert.md)
- [no-console](no-console.md)
- [no-debugger](no-debugger.md)
- [no-restricted-properties](no-restricted-properties.md) Source: http://eslint.org/docs/rules/
'lookup' is assigned a value but never used. Invalid
const lookup = Object.assign(
- 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)
) - It is read inside of a function that is passed to another function (
doSomething(function() { foo(); })
)
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;
// Write-only variables are not considered as used.
var y = 10;
y = 5;
// A read for a modification of itself is not considered as used.
var z = 0;
z = z + 1;
// 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);
}
// When a function definition destructures an array, unused entries from the array also cause warnings.
function getY([x, y]) {
return y;
}
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;
})();
var myFunc;
myFunc = setTimeout(function() {
// myFunc is considered used
myFunc();
}, 50);
// Only the second argument from the descructured array is used.
function getY([, y]) {
return y;
}
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
The line comment // exported variableName
will not work as exported
is not line-specific.
Examples of correct code for /* exported variableName */
operation:
/* exported global_var */
var global_var = 42;
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", "ignoreRestSiblings": false }]
}
}
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;
})();
ignoreRestSiblings
The ignoreRestSiblings
option is a boolean (default: false
). Using a Rest Property it is possible to "omit" properties from an object, but by default the sibling properties are marked as "unused". With this option enabled the rest property's siblings are ignored.
Examples of correct code for the { "ignoreRestSiblings": true }
option:
/*eslint no-unused-vars: ["error", { "ignoreRestSiblings": true }]*/
// 'type' is ignored because it has a rest property sibling.
var { type, ...coords } = data;
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/
for..in loops iterate over the entire prototype chain, which is virtually never what you want. Use Object.{keys,values,entries}, and iterate over the resulting array. Invalid
for (const i in fitleredDataByYear) {
- Read upRead up
- Exclude checks
disallow specified syntax (no-restricted-syntax)
JavaScript has a lot of language features, and not everyone likes all of them. As a result, some projects choose to disallow the use of certain language features altogether. For instance, you might decide to disallow the use of try-catch
or class
, or you might decide to disallow the use of the in
operator.
Rather than creating separate rules for every language feature you want to turn off, this rule allows you to configure the syntax elements you want to restrict use of. These elements are represented by their ESTree node types. For example, a function declaration is represented by FunctionDeclaration
and the with
statement is represented by WithStatement
. You may find the full list of AST node names you can use on GitHub and use the online parser to see what type of nodes your code consists of.
You can also specify [AST selectors](../developer-guide/selectors) to restrict, allowing much more precise control over syntax patterns.
Rule Details
This rule disallows specified (that is, user-defined) syntax.
Options
This rule takes a list of strings, where each string is an AST selector:
{
"rules": {
"no-restricted-syntax": ["error", "FunctionExpression", "WithStatement", "BinaryExpression[operator='in']"]
}
}
Alternatively, the rule also accepts objects, where the selector and an optional custom message are specified:
{
"rules": {
"no-restricted-syntax": [
"error",
{
"selector": "FunctionExpression",
"message": "Function expressions are not allowed."
},
{
"selector": "CallExpression[callee.name='setTimeout'][arguments.length!=2]",
"message": "setTimeout must always be invoked with two arguments."
}
]
}
}
If a custom message is specified with the message
property, ESLint will use that message when reporting occurrences of the syntax specified in the selector
property.
The string and object formats can be freely mixed in the configuration as needed.
Examples of incorrect code for this rule with the "FunctionExpression", "WithStatement", BinaryExpression[operator='in']
options:
/* eslint no-restricted-syntax: ["error", "FunctionExpression", "WithStatement", "BinaryExpression[operator='in']"] */
with (me) {
dontMess();
}
var doSomething = function () {};
foo in bar;
Examples of correct code for this rule with the "FunctionExpression", "WithStatement", BinaryExpression[operator='in']
options:
/* eslint no-restricted-syntax: ["error", "FunctionExpression", "WithStatement", "BinaryExpression[operator='in']"] */
me.dontMess();
function doSomething() {};
foo instanceof bar;
When Not To Use It
If you don't want to restrict your code from using any JavaScript features or syntax, you should not use this rule.
Related Rules
- [no-alert](no-alert.md)
- [no-console](no-console.md)
- [no-debugger](no-debugger.md)
- [no-restricted-properties](no-restricted-properties.md) Source: http://eslint.org/docs/rules/
for..in loops iterate over the entire prototype chain, which is virtually never what you want. Use Object.{keys,values,entries}, and iterate over the resulting array. Invalid
for (const m in data.keys) {
- Read upRead up
- Exclude checks
disallow specified syntax (no-restricted-syntax)
JavaScript has a lot of language features, and not everyone likes all of them. As a result, some projects choose to disallow the use of certain language features altogether. For instance, you might decide to disallow the use of try-catch
or class
, or you might decide to disallow the use of the in
operator.
Rather than creating separate rules for every language feature you want to turn off, this rule allows you to configure the syntax elements you want to restrict use of. These elements are represented by their ESTree node types. For example, a function declaration is represented by FunctionDeclaration
and the with
statement is represented by WithStatement
. You may find the full list of AST node names you can use on GitHub and use the online parser to see what type of nodes your code consists of.
You can also specify [AST selectors](../developer-guide/selectors) to restrict, allowing much more precise control over syntax patterns.
Rule Details
This rule disallows specified (that is, user-defined) syntax.
Options
This rule takes a list of strings, where each string is an AST selector:
{
"rules": {
"no-restricted-syntax": ["error", "FunctionExpression", "WithStatement", "BinaryExpression[operator='in']"]
}
}
Alternatively, the rule also accepts objects, where the selector and an optional custom message are specified:
{
"rules": {
"no-restricted-syntax": [
"error",
{
"selector": "FunctionExpression",
"message": "Function expressions are not allowed."
},
{
"selector": "CallExpression[callee.name='setTimeout'][arguments.length!=2]",
"message": "setTimeout must always be invoked with two arguments."
}
]
}
}
If a custom message is specified with the message
property, ESLint will use that message when reporting occurrences of the syntax specified in the selector
property.
The string and object formats can be freely mixed in the configuration as needed.
Examples of incorrect code for this rule with the "FunctionExpression", "WithStatement", BinaryExpression[operator='in']
options:
/* eslint no-restricted-syntax: ["error", "FunctionExpression", "WithStatement", "BinaryExpression[operator='in']"] */
with (me) {
dontMess();
}
var doSomething = function () {};
foo in bar;
Examples of correct code for this rule with the "FunctionExpression", "WithStatement", BinaryExpression[operator='in']
options:
/* eslint no-restricted-syntax: ["error", "FunctionExpression", "WithStatement", "BinaryExpression[operator='in']"] */
me.dontMess();
function doSomething() {};
foo instanceof bar;
When Not To Use It
If you don't want to restrict your code from using any JavaScript features or syntax, you should not use this rule.
Related Rules
- [no-alert](no-alert.md)
- [no-console](no-console.md)
- [no-debugger](no-debugger.md)
- [no-restricted-properties](no-restricted-properties.md) Source: http://eslint.org/docs/rules/
for..in loops iterate over the entire prototype chain, which is virtually never what you want. Use Object.{keys,values,entries}, and iterate over the resulting array. Invalid
for (const i in Array.from(keys)) {
- Read upRead up
- Exclude checks
disallow specified syntax (no-restricted-syntax)
JavaScript has a lot of language features, and not everyone likes all of them. As a result, some projects choose to disallow the use of certain language features altogether. For instance, you might decide to disallow the use of try-catch
or class
, or you might decide to disallow the use of the in
operator.
Rather than creating separate rules for every language feature you want to turn off, this rule allows you to configure the syntax elements you want to restrict use of. These elements are represented by their ESTree node types. For example, a function declaration is represented by FunctionDeclaration
and the with
statement is represented by WithStatement
. You may find the full list of AST node names you can use on GitHub and use the online parser to see what type of nodes your code consists of.
You can also specify [AST selectors](../developer-guide/selectors) to restrict, allowing much more precise control over syntax patterns.
Rule Details
This rule disallows specified (that is, user-defined) syntax.
Options
This rule takes a list of strings, where each string is an AST selector:
{
"rules": {
"no-restricted-syntax": ["error", "FunctionExpression", "WithStatement", "BinaryExpression[operator='in']"]
}
}
Alternatively, the rule also accepts objects, where the selector and an optional custom message are specified:
{
"rules": {
"no-restricted-syntax": [
"error",
{
"selector": "FunctionExpression",
"message": "Function expressions are not allowed."
},
{
"selector": "CallExpression[callee.name='setTimeout'][arguments.length!=2]",
"message": "setTimeout must always be invoked with two arguments."
}
]
}
}
If a custom message is specified with the message
property, ESLint will use that message when reporting occurrences of the syntax specified in the selector
property.
The string and object formats can be freely mixed in the configuration as needed.
Examples of incorrect code for this rule with the "FunctionExpression", "WithStatement", BinaryExpression[operator='in']
options:
/* eslint no-restricted-syntax: ["error", "FunctionExpression", "WithStatement", "BinaryExpression[operator='in']"] */
with (me) {
dontMess();
}
var doSomething = function () {};
foo in bar;
Examples of correct code for this rule with the "FunctionExpression", "WithStatement", BinaryExpression[operator='in']
options:
/* eslint no-restricted-syntax: ["error", "FunctionExpression", "WithStatement", "BinaryExpression[operator='in']"] */
me.dontMess();
function doSomething() {};
foo instanceof bar;
When Not To Use It
If you don't want to restrict your code from using any JavaScript features or syntax, you should not use this rule.
Related Rules
- [no-alert](no-alert.md)
- [no-console](no-console.md)
- [no-debugger](no-debugger.md)
- [no-restricted-properties](no-restricted-properties.md) Source: http://eslint.org/docs/rules/
The body of a for-in should be wrapped in an if statement to filter unwanted properties from the prototype. Invalid
for (const d in fitleredDataByYear) {
- Read upRead up
- Exclude checks
Require Guarding for-in (guard-for-in)
Looping over objects with a for in
loop will include properties that are inherited through the prototype chain. This behavior can lead to unexpected items in your for loop.
for (key in foo) {
doSomething(key);
}
Note that simply checking foo.hasOwnProperty(key)
is likely to cause an error in some cases; see [no-prototype-builtins](no-prototype-builtins.md).
Rule Details
This rule is aimed at preventing unexpected behavior that could arise from using a for in
loop without filtering the results in the loop. As such, it will warn when for in
loops do not filter their results with an if
statement.
Examples of incorrect code for this rule:
/*eslint guard-for-in: "error"*/
for (key in foo) {
doSomething(key);
}
Examples of correct code for this rule:
/*eslint guard-for-in: "error"*/
for (key in foo) {
if (Object.prototype.hasOwnProperty.call(foo, key)) {
doSomething(key);
}
if ({}.hasOwnProperty.call(foo, key)) {
doSomething(key);
}
}
Related Rules
- [no-prototype-builtins](no-prototype-builtins.md)
Further Reading
for..in loops iterate over the entire prototype chain, which is virtually never what you want. Use Object.{keys,values,entries}, and iterate over the resulting array. Invalid
for (const j in fitleredDataByYear) {
- Read upRead up
- Exclude checks
disallow specified syntax (no-restricted-syntax)
JavaScript has a lot of language features, and not everyone likes all of them. As a result, some projects choose to disallow the use of certain language features altogether. For instance, you might decide to disallow the use of try-catch
or class
, or you might decide to disallow the use of the in
operator.
Rather than creating separate rules for every language feature you want to turn off, this rule allows you to configure the syntax elements you want to restrict use of. These elements are represented by their ESTree node types. For example, a function declaration is represented by FunctionDeclaration
and the with
statement is represented by WithStatement
. You may find the full list of AST node names you can use on GitHub and use the online parser to see what type of nodes your code consists of.
You can also specify [AST selectors](../developer-guide/selectors) to restrict, allowing much more precise control over syntax patterns.
Rule Details
This rule disallows specified (that is, user-defined) syntax.
Options
This rule takes a list of strings, where each string is an AST selector:
{
"rules": {
"no-restricted-syntax": ["error", "FunctionExpression", "WithStatement", "BinaryExpression[operator='in']"]
}
}
Alternatively, the rule also accepts objects, where the selector and an optional custom message are specified:
{
"rules": {
"no-restricted-syntax": [
"error",
{
"selector": "FunctionExpression",
"message": "Function expressions are not allowed."
},
{
"selector": "CallExpression[callee.name='setTimeout'][arguments.length!=2]",
"message": "setTimeout must always be invoked with two arguments."
}
]
}
}
If a custom message is specified with the message
property, ESLint will use that message when reporting occurrences of the syntax specified in the selector
property.
The string and object formats can be freely mixed in the configuration as needed.
Examples of incorrect code for this rule with the "FunctionExpression", "WithStatement", BinaryExpression[operator='in']
options:
/* eslint no-restricted-syntax: ["error", "FunctionExpression", "WithStatement", "BinaryExpression[operator='in']"] */
with (me) {
dontMess();
}
var doSomething = function () {};
foo in bar;
Examples of correct code for this rule with the "FunctionExpression", "WithStatement", BinaryExpression[operator='in']
options:
/* eslint no-restricted-syntax: ["error", "FunctionExpression", "WithStatement", "BinaryExpression[operator='in']"] */
me.dontMess();
function doSomething() {};
foo instanceof bar;
When Not To Use It
If you don't want to restrict your code from using any JavaScript features or syntax, you should not use this rule.
Related Rules
- [no-alert](no-alert.md)
- [no-console](no-console.md)
- [no-debugger](no-debugger.md)
- [no-restricted-properties](no-restricted-properties.md) Source: http://eslint.org/docs/rules/
The object literal notation {} is preferrable. Open
const object = new Object()
- Read upRead up
- Exclude checks
disallow Object
constructors (no-new-object)
The Object
constructor is used to create new generic objects in JavaScript, such as:
var myObject = new Object();
However, this is no different from using the more concise object literal syntax:
var myObject = {};
For this reason, many prefer to always use the object literal syntax and never use the Object
constructor.
While there are no performance differences between the two approaches, the byte savings and conciseness of the object literal form is what has made it the de facto way of creating new objects.
Rule Details
This rule disallows Object
constructors.
Examples of incorrect code for this rule:
/*eslint no-new-object: "error"*/
var myObject = new Object();
var myObject = new Object;
Examples of correct code for this rule:
/*eslint no-new-object: "error"*/
var myObject = new CustomObject();
var myObject = {};
When Not To Use It
If you wish to allow the use of the Object
constructor, you can safely turn this rule off.
Related Rules
- [no-array-constructor](no-array-constructor.md)
- [no-new-wrappers](no-new-wrappers.md) Source: http://eslint.org/docs/rules/