Showing 16 of 16 total issues
Unexpected dangling '_' in '_items'. Open
this._items = value;
- Read upRead up
- Exclude checks
disallow dangling underscores in identifiers (no-underscore-dangle)
As far as naming conventions for identifiers go, dangling underscores may be the most polarizing in JavaScript. Dangling underscores are underscores at either the beginning or end of an identifier, such as:
var _foo;
There is actually a long history of using dangling underscores to indicate "private" members of objects in JavaScript (though JavaScript doesn't have truly private members, this convention served as a warning). This began with SpiderMonkey adding nonstandard methods such as __defineGetter__()
. The intent with the underscores was to make it obvious that this method was special in some way. Since that time, using a single underscore prefix has become popular as a way to indicate "private" members of objects.
Whether or not you choose to allow dangling underscores in identifiers is purely a convention and has no effect on performance, readability, or complexity. It's purely a preference.
Rule Details
This rule disallows dangling underscores in identifiers.
Examples of incorrect code for this rule:
/*eslint no-underscore-dangle: "error"*/
var foo_;
var __proto__ = {};
foo._bar();
Examples of correct code for this rule:
/*eslint no-underscore-dangle: "error"*/
var _ = require('underscore');
var obj = _.contains(items, item);
obj.__proto__ = {};
var file = __filename;
Options
This rule has an object option:
-
"allow"
allows specified identifiers to have dangling underscores -
"allowAfterThis": false
(default) disallows dangling underscores in members of thethis
object -
"allowAfterSuper": false
(default) disallows dangling underscores in members of thesuper
object
allow
Examples of additional correct code for this rule with the { "allow": ["foo_", "_bar"] }
option:
/*eslint no-underscore-dangle: ["error", { "allow": ["foo_", "_bar"] }]*/
var foo_;
foo._bar();
allowAfterThis
Examples of correct code for this rule with the { "allowAfterThis": true }
option:
/*eslint no-underscore-dangle: ["error", { "allowAfterThis": true }]*/
var a = this.foo_;
this._bar();
allowAfterSuper
Examples of correct code for this rule with the { "allowAfterSuper": true }
option:
/*eslint no-underscore-dangle: ["error", { "allowAfterSuper": true }]*/
var a = super.foo_;
super._bar();
When Not To Use It
If you want to allow dangling underscores in identifiers, then you can safely turn this rule off. Source: http://eslint.org/docs/rules/
Unexpected dangling '_' in '_expected'. Open
return Math.round(this._expected * 10) / 10;
- Read upRead up
- Exclude checks
disallow dangling underscores in identifiers (no-underscore-dangle)
As far as naming conventions for identifiers go, dangling underscores may be the most polarizing in JavaScript. Dangling underscores are underscores at either the beginning or end of an identifier, such as:
var _foo;
There is actually a long history of using dangling underscores to indicate "private" members of objects in JavaScript (though JavaScript doesn't have truly private members, this convention served as a warning). This began with SpiderMonkey adding nonstandard methods such as __defineGetter__()
. The intent with the underscores was to make it obvious that this method was special in some way. Since that time, using a single underscore prefix has become popular as a way to indicate "private" members of objects.
Whether or not you choose to allow dangling underscores in identifiers is purely a convention and has no effect on performance, readability, or complexity. It's purely a preference.
Rule Details
This rule disallows dangling underscores in identifiers.
Examples of incorrect code for this rule:
/*eslint no-underscore-dangle: "error"*/
var foo_;
var __proto__ = {};
foo._bar();
Examples of correct code for this rule:
/*eslint no-underscore-dangle: "error"*/
var _ = require('underscore');
var obj = _.contains(items, item);
obj.__proto__ = {};
var file = __filename;
Options
This rule has an object option:
-
"allow"
allows specified identifiers to have dangling underscores -
"allowAfterThis": false
(default) disallows dangling underscores in members of thethis
object -
"allowAfterSuper": false
(default) disallows dangling underscores in members of thesuper
object
allow
Examples of additional correct code for this rule with the { "allow": ["foo_", "_bar"] }
option:
/*eslint no-underscore-dangle: ["error", { "allow": ["foo_", "_bar"] }]*/
var foo_;
foo._bar();
allowAfterThis
Examples of correct code for this rule with the { "allowAfterThis": true }
option:
/*eslint no-underscore-dangle: ["error", { "allowAfterThis": true }]*/
var a = this.foo_;
this._bar();
allowAfterSuper
Examples of correct code for this rule with the { "allowAfterSuper": true }
option:
/*eslint no-underscore-dangle: ["error", { "allowAfterSuper": true }]*/
var a = super.foo_;
super._bar();
When Not To Use It
If you want to allow dangling underscores in identifiers, then you can safely turn this rule off. Source: http://eslint.org/docs/rules/
Unexpected dangling '_' in '_criticalValue'. Open
this._pessimistic = expected + (standardDeviation * this._criticalValue);
- Read upRead up
- Exclude checks
disallow dangling underscores in identifiers (no-underscore-dangle)
As far as naming conventions for identifiers go, dangling underscores may be the most polarizing in JavaScript. Dangling underscores are underscores at either the beginning or end of an identifier, such as:
var _foo;
There is actually a long history of using dangling underscores to indicate "private" members of objects in JavaScript (though JavaScript doesn't have truly private members, this convention served as a warning). This began with SpiderMonkey adding nonstandard methods such as __defineGetter__()
. The intent with the underscores was to make it obvious that this method was special in some way. Since that time, using a single underscore prefix has become popular as a way to indicate "private" members of objects.
Whether or not you choose to allow dangling underscores in identifiers is purely a convention and has no effect on performance, readability, or complexity. It's purely a preference.
Rule Details
This rule disallows dangling underscores in identifiers.
Examples of incorrect code for this rule:
/*eslint no-underscore-dangle: "error"*/
var foo_;
var __proto__ = {};
foo._bar();
Examples of correct code for this rule:
/*eslint no-underscore-dangle: "error"*/
var _ = require('underscore');
var obj = _.contains(items, item);
obj.__proto__ = {};
var file = __filename;
Options
This rule has an object option:
-
"allow"
allows specified identifiers to have dangling underscores -
"allowAfterThis": false
(default) disallows dangling underscores in members of thethis
object -
"allowAfterSuper": false
(default) disallows dangling underscores in members of thesuper
object
allow
Examples of additional correct code for this rule with the { "allow": ["foo_", "_bar"] }
option:
/*eslint no-underscore-dangle: ["error", { "allow": ["foo_", "_bar"] }]*/
var foo_;
foo._bar();
allowAfterThis
Examples of correct code for this rule with the { "allowAfterThis": true }
option:
/*eslint no-underscore-dangle: ["error", { "allowAfterThis": true }]*/
var a = this.foo_;
this._bar();
allowAfterSuper
Examples of correct code for this rule with the { "allowAfterSuper": true }
option:
/*eslint no-underscore-dangle: ["error", { "allowAfterSuper": true }]*/
var a = super.foo_;
super._bar();
When Not To Use It
If you want to allow dangling underscores in identifiers, then you can safely turn this rule off. Source: http://eslint.org/docs/rules/
Expected 'this' to be used by class method 'findCriticalValue'. Open
findCriticalValue(value) {
- Read upRead up
- Exclude checks
Enforce that class methods utilize this
(class-methods-use-this)
If a class method does not use this
, it can safely be made a static function.
It's possible to have a class method which doesn't use this
, such as:
class A {
constructor() {
this.a = "hi";
}
print() {
console.log(this.a);
}
sayHi() {
console.log("hi");
}
}
let a = new A();
a.sayHi(); // => "hi"
In the example above, the sayHi
method doesn't use this
, so we can make it a static method:
class A {
constructor() {
this.a = "hi";
}
print() {
console.log(this.a);
}
static sayHi() {
console.log("hi");
}
}
A.sayHi(); // => "hi"
Also note in the above examples that the code calling the function on an instance of the class (let a = new A(); a.sayHi();
) changes to calling it on the class itself (A.sayHi();
).
Rule Details
This rule is aimed to flag class methods that do not use this
.
Examples of incorrect code for this rule:
/*eslint class-methods-use-this: "error"*/
/*eslint-env es6*/
class A {
foo() {
console.log("Hello World"); /*error Expected 'this' to be used by class method 'foo'.*/
}
}
Examples of correct code for this rule:
/*eslint class-methods-use-this: "error"*/
/*eslint-env es6*/
class A {
foo() {
this.bar = "Hello World"; // OK, this is used
}
}
class A {
constructor() {
// OK. constructor is exempt
}
}
class A {
static foo() {
// OK. static methods aren't expected to use this.
}
}
Options
Exceptions
"class-methods-use-this": [<enabled>, { "exceptMethods": [<...exceptions>] }]</enabled>
The exceptMethods
option allows you to pass an array of method names for which you would like to ignore warnings.
Examples of incorrect code for this rule when used without exceptMethods:
/*eslint class-methods-use-this: "error"*/
class A {
foo() {
}
}
Examples of correct code for this rule when used with exceptMethods:
/*eslint class-methods-use-this: ["error", { "exceptMethods": ["foo"] }] */
class A {
foo() {
}
}
Source: http://eslint.org/docs/rules/
'Math.pow' is restricted from being used. Use the exponentiation operator (**) instead. Open
.map(x => Math.pow(x.standardDeviation, 2))
- Read upRead up
- Exclude checks
disallow certain object properties (no-restricted-properties)
Certain properties on objects may be disallowed in a codebase. This is useful for deprecating an API or restricting usage of a module's methods. For example, you may want to disallow using describe.only
when using Mocha or telling people to use Object.assign
instead of _.extend
.
Rule Details
This rule looks for accessing a given property key on a given object name, either when reading the property's value or invoking it as a function. You may specify an optional message to indicate an alternative API or a reason for the restriction.
Options
This rule takes a list of objects, where the object name and property names are specified:
{
"rules": {
"no-restricted-properties": [2, {
"object": "disallowedObjectName",
"property": "disallowedPropertyName"
}]
}
}
Multiple object/property values can be disallowed, and you can specify an optional message:
{
"rules": {
"no-restricted-properties": [2, {
"object": "disallowedObjectName",
"property": "disallowedPropertyName"
}, {
"object": "disallowedObjectName",
"property": "anotherDisallowedPropertyName",
"message": "Please use allowedObjectName.allowedPropertyName."
}]
}
}
If the object name is omitted, the property is disallowed for all objects:
{
"rules": {
"no-restricted-properties": [2, {
"property": "__defineGetter__",
"message": "Please use Object.defineProperty instead."
}]
}
}
If the property name is omitted, accessing any property of the given object is disallowed:
{
"rules": {
"no-restricted-properties": [2, {
"object": "require",
"message": "Please call require() directly."
}]
}
}
Examples of incorrect code for this rule:
/* eslint no-restricted-properties: [2, {
"object": "disallowedObjectName",
"property": "disallowedPropertyName"
}] */
var example = disallowedObjectName.disallowedPropertyName; /*error Disallowed object property: disallowedObjectName.disallowedPropertyName.*/
disallowedObjectName.disallowedPropertyName(); /*error Disallowed object property: disallowedObjectName.disallowedPropertyName.*/
/* eslint no-restricted-properties: [2, {
"property": "__defineGetter__"
}] */
foo.__defineGetter__(bar, baz);
/* eslint no-restricted-properties: [2, {
"object": "require"
}] */
require.resolve('foo');
Examples of correct code for this rule:
/* eslint no-restricted-properties: [2, {
"object": "disallowedObjectName",
"property": "disallowedPropertyName"
}] */
var example = disallowedObjectName.somePropertyName;
allowedObjectName.disallowedPropertyName();
/* eslint no-restricted-properties: [2, {
"object": "require"
}] */
require('foo');
When Not To Use It
If you don't have any object/property combinations to restrict, you should not use this rule.
Related Rules
- [no-restricted-globals](no-restricted-globals.md)
- [no-restricted-syntax](no-restricted-syntax.md) Source: http://eslint.org/docs/rules/
Unexpected dangling '_' in '_optimistic'. Open
this._optimistic = expected - (standardDeviation * this._criticalValue);
- Read upRead up
- Exclude checks
disallow dangling underscores in identifiers (no-underscore-dangle)
As far as naming conventions for identifiers go, dangling underscores may be the most polarizing in JavaScript. Dangling underscores are underscores at either the beginning or end of an identifier, such as:
var _foo;
There is actually a long history of using dangling underscores to indicate "private" members of objects in JavaScript (though JavaScript doesn't have truly private members, this convention served as a warning). This began with SpiderMonkey adding nonstandard methods such as __defineGetter__()
. The intent with the underscores was to make it obvious that this method was special in some way. Since that time, using a single underscore prefix has become popular as a way to indicate "private" members of objects.
Whether or not you choose to allow dangling underscores in identifiers is purely a convention and has no effect on performance, readability, or complexity. It's purely a preference.
Rule Details
This rule disallows dangling underscores in identifiers.
Examples of incorrect code for this rule:
/*eslint no-underscore-dangle: "error"*/
var foo_;
var __proto__ = {};
foo._bar();
Examples of correct code for this rule:
/*eslint no-underscore-dangle: "error"*/
var _ = require('underscore');
var obj = _.contains(items, item);
obj.__proto__ = {};
var file = __filename;
Options
This rule has an object option:
-
"allow"
allows specified identifiers to have dangling underscores -
"allowAfterThis": false
(default) disallows dangling underscores in members of thethis
object -
"allowAfterSuper": false
(default) disallows dangling underscores in members of thesuper
object
allow
Examples of additional correct code for this rule with the { "allow": ["foo_", "_bar"] }
option:
/*eslint no-underscore-dangle: ["error", { "allow": ["foo_", "_bar"] }]*/
var foo_;
foo._bar();
allowAfterThis
Examples of correct code for this rule with the { "allowAfterThis": true }
option:
/*eslint no-underscore-dangle: ["error", { "allowAfterThis": true }]*/
var a = this.foo_;
this._bar();
allowAfterSuper
Examples of correct code for this rule with the { "allowAfterSuper": true }
option:
/*eslint no-underscore-dangle: ["error", { "allowAfterSuper": true }]*/
var a = super.foo_;
super._bar();
When Not To Use It
If you want to allow dangling underscores in identifiers, then you can safely turn this rule off. Source: http://eslint.org/docs/rules/
Unexpected dangling '_' in '_optimistic'. Open
return Math.round(this._optimistic * 10) / 10;
- Read upRead up
- Exclude checks
disallow dangling underscores in identifiers (no-underscore-dangle)
As far as naming conventions for identifiers go, dangling underscores may be the most polarizing in JavaScript. Dangling underscores are underscores at either the beginning or end of an identifier, such as:
var _foo;
There is actually a long history of using dangling underscores to indicate "private" members of objects in JavaScript (though JavaScript doesn't have truly private members, this convention served as a warning). This began with SpiderMonkey adding nonstandard methods such as __defineGetter__()
. The intent with the underscores was to make it obvious that this method was special in some way. Since that time, using a single underscore prefix has become popular as a way to indicate "private" members of objects.
Whether or not you choose to allow dangling underscores in identifiers is purely a convention and has no effect on performance, readability, or complexity. It's purely a preference.
Rule Details
This rule disallows dangling underscores in identifiers.
Examples of incorrect code for this rule:
/*eslint no-underscore-dangle: "error"*/
var foo_;
var __proto__ = {};
foo._bar();
Examples of correct code for this rule:
/*eslint no-underscore-dangle: "error"*/
var _ = require('underscore');
var obj = _.contains(items, item);
obj.__proto__ = {};
var file = __filename;
Options
This rule has an object option:
-
"allow"
allows specified identifiers to have dangling underscores -
"allowAfterThis": false
(default) disallows dangling underscores in members of thethis
object -
"allowAfterSuper": false
(default) disallows dangling underscores in members of thesuper
object
allow
Examples of additional correct code for this rule with the { "allow": ["foo_", "_bar"] }
option:
/*eslint no-underscore-dangle: ["error", { "allow": ["foo_", "_bar"] }]*/
var foo_;
foo._bar();
allowAfterThis
Examples of correct code for this rule with the { "allowAfterThis": true }
option:
/*eslint no-underscore-dangle: ["error", { "allowAfterThis": true }]*/
var a = this.foo_;
this._bar();
allowAfterSuper
Examples of correct code for this rule with the { "allowAfterSuper": true }
option:
/*eslint no-underscore-dangle: ["error", { "allowAfterSuper": true }]*/
var a = super.foo_;
super._bar();
When Not To Use It
If you want to allow dangling underscores in identifiers, then you can safely turn this rule off. Source: http://eslint.org/docs/rules/
Unexpected dangling '_' in '_pessimistic'. Open
this._pessimistic = expected + (standardDeviation * this._criticalValue);
- Read upRead up
- Exclude checks
disallow dangling underscores in identifiers (no-underscore-dangle)
As far as naming conventions for identifiers go, dangling underscores may be the most polarizing in JavaScript. Dangling underscores are underscores at either the beginning or end of an identifier, such as:
var _foo;
There is actually a long history of using dangling underscores to indicate "private" members of objects in JavaScript (though JavaScript doesn't have truly private members, this convention served as a warning). This began with SpiderMonkey adding nonstandard methods such as __defineGetter__()
. The intent with the underscores was to make it obvious that this method was special in some way. Since that time, using a single underscore prefix has become popular as a way to indicate "private" members of objects.
Whether or not you choose to allow dangling underscores in identifiers is purely a convention and has no effect on performance, readability, or complexity. It's purely a preference.
Rule Details
This rule disallows dangling underscores in identifiers.
Examples of incorrect code for this rule:
/*eslint no-underscore-dangle: "error"*/
var foo_;
var __proto__ = {};
foo._bar();
Examples of correct code for this rule:
/*eslint no-underscore-dangle: "error"*/
var _ = require('underscore');
var obj = _.contains(items, item);
obj.__proto__ = {};
var file = __filename;
Options
This rule has an object option:
-
"allow"
allows specified identifiers to have dangling underscores -
"allowAfterThis": false
(default) disallows dangling underscores in members of thethis
object -
"allowAfterSuper": false
(default) disallows dangling underscores in members of thesuper
object
allow
Examples of additional correct code for this rule with the { "allow": ["foo_", "_bar"] }
option:
/*eslint no-underscore-dangle: ["error", { "allow": ["foo_", "_bar"] }]*/
var foo_;
foo._bar();
allowAfterThis
Examples of correct code for this rule with the { "allowAfterThis": true }
option:
/*eslint no-underscore-dangle: ["error", { "allowAfterThis": true }]*/
var a = this.foo_;
this._bar();
allowAfterSuper
Examples of correct code for this rule with the { "allowAfterSuper": true }
option:
/*eslint no-underscore-dangle: ["error", { "allowAfterSuper": true }]*/
var a = super.foo_;
super._bar();
When Not To Use It
If you want to allow dangling underscores in identifiers, then you can safely turn this rule off. Source: http://eslint.org/docs/rules/
Unexpected dangling '_' in '_criticalValue'. Open
this._optimistic = expected - (standardDeviation * this._criticalValue);
- Read upRead up
- Exclude checks
disallow dangling underscores in identifiers (no-underscore-dangle)
As far as naming conventions for identifiers go, dangling underscores may be the most polarizing in JavaScript. Dangling underscores are underscores at either the beginning or end of an identifier, such as:
var _foo;
There is actually a long history of using dangling underscores to indicate "private" members of objects in JavaScript (though JavaScript doesn't have truly private members, this convention served as a warning). This began with SpiderMonkey adding nonstandard methods such as __defineGetter__()
. The intent with the underscores was to make it obvious that this method was special in some way. Since that time, using a single underscore prefix has become popular as a way to indicate "private" members of objects.
Whether or not you choose to allow dangling underscores in identifiers is purely a convention and has no effect on performance, readability, or complexity. It's purely a preference.
Rule Details
This rule disallows dangling underscores in identifiers.
Examples of incorrect code for this rule:
/*eslint no-underscore-dangle: "error"*/
var foo_;
var __proto__ = {};
foo._bar();
Examples of correct code for this rule:
/*eslint no-underscore-dangle: "error"*/
var _ = require('underscore');
var obj = _.contains(items, item);
obj.__proto__ = {};
var file = __filename;
Options
This rule has an object option:
-
"allow"
allows specified identifiers to have dangling underscores -
"allowAfterThis": false
(default) disallows dangling underscores in members of thethis
object -
"allowAfterSuper": false
(default) disallows dangling underscores in members of thesuper
object
allow
Examples of additional correct code for this rule with the { "allow": ["foo_", "_bar"] }
option:
/*eslint no-underscore-dangle: ["error", { "allow": ["foo_", "_bar"] }]*/
var foo_;
foo._bar();
allowAfterThis
Examples of correct code for this rule with the { "allowAfterThis": true }
option:
/*eslint no-underscore-dangle: ["error", { "allowAfterThis": true }]*/
var a = this.foo_;
this._bar();
allowAfterSuper
Examples of correct code for this rule with the { "allowAfterSuper": true }
option:
/*eslint no-underscore-dangle: ["error", { "allowAfterSuper": true }]*/
var a = super.foo_;
super._bar();
When Not To Use It
If you want to allow dangling underscores in identifiers, then you can safely turn this rule off. Source: http://eslint.org/docs/rules/
Expected 'this' to be used by class method 'estimateItem'. Open
estimateItem({ optimistic, pessimistic, likely }) {
- Read upRead up
- Exclude checks
Enforce that class methods utilize this
(class-methods-use-this)
If a class method does not use this
, it can safely be made a static function.
It's possible to have a class method which doesn't use this
, such as:
class A {
constructor() {
this.a = "hi";
}
print() {
console.log(this.a);
}
sayHi() {
console.log("hi");
}
}
let a = new A();
a.sayHi(); // => "hi"
In the example above, the sayHi
method doesn't use this
, so we can make it a static method:
class A {
constructor() {
this.a = "hi";
}
print() {
console.log(this.a);
}
static sayHi() {
console.log("hi");
}
}
A.sayHi(); // => "hi"
Also note in the above examples that the code calling the function on an instance of the class (let a = new A(); a.sayHi();
) changes to calling it on the class itself (A.sayHi();
).
Rule Details
This rule is aimed to flag class methods that do not use this
.
Examples of incorrect code for this rule:
/*eslint class-methods-use-this: "error"*/
/*eslint-env es6*/
class A {
foo() {
console.log("Hello World"); /*error Expected 'this' to be used by class method 'foo'.*/
}
}
Examples of correct code for this rule:
/*eslint class-methods-use-this: "error"*/
/*eslint-env es6*/
class A {
foo() {
this.bar = "Hello World"; // OK, this is used
}
}
class A {
constructor() {
// OK. constructor is exempt
}
}
class A {
static foo() {
// OK. static methods aren't expected to use this.
}
}
Options
Exceptions
"class-methods-use-this": [<enabled>, { "exceptMethods": [<...exceptions>] }]</enabled>
The exceptMethods
option allows you to pass an array of method names for which you would like to ignore warnings.
Examples of incorrect code for this rule when used without exceptMethods:
/*eslint class-methods-use-this: "error"*/
class A {
foo() {
}
}
Examples of correct code for this rule when used with exceptMethods:
/*eslint class-methods-use-this: ["error", { "exceptMethods": ["foo"] }] */
class A {
foo() {
}
}
Source: http://eslint.org/docs/rules/
Unexpected dangling '_' in '_items'. Open
const estimates = this._items.map(this.estimateItem);
- Read upRead up
- Exclude checks
disallow dangling underscores in identifiers (no-underscore-dangle)
As far as naming conventions for identifiers go, dangling underscores may be the most polarizing in JavaScript. Dangling underscores are underscores at either the beginning or end of an identifier, such as:
var _foo;
There is actually a long history of using dangling underscores to indicate "private" members of objects in JavaScript (though JavaScript doesn't have truly private members, this convention served as a warning). This began with SpiderMonkey adding nonstandard methods such as __defineGetter__()
. The intent with the underscores was to make it obvious that this method was special in some way. Since that time, using a single underscore prefix has become popular as a way to indicate "private" members of objects.
Whether or not you choose to allow dangling underscores in identifiers is purely a convention and has no effect on performance, readability, or complexity. It's purely a preference.
Rule Details
This rule disallows dangling underscores in identifiers.
Examples of incorrect code for this rule:
/*eslint no-underscore-dangle: "error"*/
var foo_;
var __proto__ = {};
foo._bar();
Examples of correct code for this rule:
/*eslint no-underscore-dangle: "error"*/
var _ = require('underscore');
var obj = _.contains(items, item);
obj.__proto__ = {};
var file = __filename;
Options
This rule has an object option:
-
"allow"
allows specified identifiers to have dangling underscores -
"allowAfterThis": false
(default) disallows dangling underscores in members of thethis
object -
"allowAfterSuper": false
(default) disallows dangling underscores in members of thesuper
object
allow
Examples of additional correct code for this rule with the { "allow": ["foo_", "_bar"] }
option:
/*eslint no-underscore-dangle: ["error", { "allow": ["foo_", "_bar"] }]*/
var foo_;
foo._bar();
allowAfterThis
Examples of correct code for this rule with the { "allowAfterThis": true }
option:
/*eslint no-underscore-dangle: ["error", { "allowAfterThis": true }]*/
var a = this.foo_;
this._bar();
allowAfterSuper
Examples of correct code for this rule with the { "allowAfterSuper": true }
option:
/*eslint no-underscore-dangle: ["error", { "allowAfterSuper": true }]*/
var a = super.foo_;
super._bar();
When Not To Use It
If you want to allow dangling underscores in identifiers, then you can safely turn this rule off. Source: http://eslint.org/docs/rules/
Unexpected dangling '_' in '_pessimistic'. Open
return Math.round(this._pessimistic * 10) / 10;
- Read upRead up
- Exclude checks
disallow dangling underscores in identifiers (no-underscore-dangle)
As far as naming conventions for identifiers go, dangling underscores may be the most polarizing in JavaScript. Dangling underscores are underscores at either the beginning or end of an identifier, such as:
var _foo;
There is actually a long history of using dangling underscores to indicate "private" members of objects in JavaScript (though JavaScript doesn't have truly private members, this convention served as a warning). This began with SpiderMonkey adding nonstandard methods such as __defineGetter__()
. The intent with the underscores was to make it obvious that this method was special in some way. Since that time, using a single underscore prefix has become popular as a way to indicate "private" members of objects.
Whether or not you choose to allow dangling underscores in identifiers is purely a convention and has no effect on performance, readability, or complexity. It's purely a preference.
Rule Details
This rule disallows dangling underscores in identifiers.
Examples of incorrect code for this rule:
/*eslint no-underscore-dangle: "error"*/
var foo_;
var __proto__ = {};
foo._bar();
Examples of correct code for this rule:
/*eslint no-underscore-dangle: "error"*/
var _ = require('underscore');
var obj = _.contains(items, item);
obj.__proto__ = {};
var file = __filename;
Options
This rule has an object option:
-
"allow"
allows specified identifiers to have dangling underscores -
"allowAfterThis": false
(default) disallows dangling underscores in members of thethis
object -
"allowAfterSuper": false
(default) disallows dangling underscores in members of thesuper
object
allow
Examples of additional correct code for this rule with the { "allow": ["foo_", "_bar"] }
option:
/*eslint no-underscore-dangle: ["error", { "allow": ["foo_", "_bar"] }]*/
var foo_;
foo._bar();
allowAfterThis
Examples of correct code for this rule with the { "allowAfterThis": true }
option:
/*eslint no-underscore-dangle: ["error", { "allowAfterThis": true }]*/
var a = this.foo_;
this._bar();
allowAfterSuper
Examples of correct code for this rule with the { "allowAfterSuper": true }
option:
/*eslint no-underscore-dangle: ["error", { "allowAfterSuper": true }]*/
var a = super.foo_;
super._bar();
When Not To Use It
If you want to allow dangling underscores in identifiers, then you can safely turn this rule off. Source: http://eslint.org/docs/rules/
Unexpected dangling '_' in '_expected'. Open
this._expected = expected;
- Read upRead up
- Exclude checks
disallow dangling underscores in identifiers (no-underscore-dangle)
As far as naming conventions for identifiers go, dangling underscores may be the most polarizing in JavaScript. Dangling underscores are underscores at either the beginning or end of an identifier, such as:
var _foo;
There is actually a long history of using dangling underscores to indicate "private" members of objects in JavaScript (though JavaScript doesn't have truly private members, this convention served as a warning). This began with SpiderMonkey adding nonstandard methods such as __defineGetter__()
. The intent with the underscores was to make it obvious that this method was special in some way. Since that time, using a single underscore prefix has become popular as a way to indicate "private" members of objects.
Whether or not you choose to allow dangling underscores in identifiers is purely a convention and has no effect on performance, readability, or complexity. It's purely a preference.
Rule Details
This rule disallows dangling underscores in identifiers.
Examples of incorrect code for this rule:
/*eslint no-underscore-dangle: "error"*/
var foo_;
var __proto__ = {};
foo._bar();
Examples of correct code for this rule:
/*eslint no-underscore-dangle: "error"*/
var _ = require('underscore');
var obj = _.contains(items, item);
obj.__proto__ = {};
var file = __filename;
Options
This rule has an object option:
-
"allow"
allows specified identifiers to have dangling underscores -
"allowAfterThis": false
(default) disallows dangling underscores in members of thethis
object -
"allowAfterSuper": false
(default) disallows dangling underscores in members of thesuper
object
allow
Examples of additional correct code for this rule with the { "allow": ["foo_", "_bar"] }
option:
/*eslint no-underscore-dangle: ["error", { "allow": ["foo_", "_bar"] }]*/
var foo_;
foo._bar();
allowAfterThis
Examples of correct code for this rule with the { "allowAfterThis": true }
option:
/*eslint no-underscore-dangle: ["error", { "allowAfterThis": true }]*/
var a = this.foo_;
this._bar();
allowAfterSuper
Examples of correct code for this rule with the { "allowAfterSuper": true }
option:
/*eslint no-underscore-dangle: ["error", { "allowAfterSuper": true }]*/
var a = super.foo_;
super._bar();
When Not To Use It
If you want to allow dangling underscores in identifiers, then you can safely turn this rule off. Source: http://eslint.org/docs/rules/
Unexpected mix of '+' and '*'. Open
expected: (optimistic + 4 * likely + pessimistic) / 6,
- Read upRead up
- Exclude checks
Disallow mixes of different operators (no-mixed-operators)
Enclosing complex expressions by parentheses clarifies the developer's intention, which makes the code more readable. This rule warns when different operators are used consecutively without parentheses in an expression.
var foo = a && b || c || d; /*BAD: Unexpected mix of '&&' and '||'.*/
var foo = (a && b) || c || d; /*GOOD*/
var foo = a && (b || c || d); /*GOOD*/
Rule Details
This rule checks BinaryExpression
and LogicalExpression
.
This rule may conflict with [no-extra-parens](no-extra-parens.md) rule.
If you use both this and [no-extra-parens](no-extra-parens.md) rule together, you need to use the nestedBinaryExpressions
option of [no-extra-parens](no-extra-parens.md) rule.
Examples of incorrect code for this rule:
/*eslint no-mixed-operators: "error"*/
var foo = a && b < 0 || c > 0 || d + 1 === 0;
var foo = a + b * c;
Examples of correct code for this rule:
/*eslint no-mixed-operators: "error"*/
var foo = a || b || c;
var foo = a && b && c;
var foo = (a && b < 0) || c > 0 || d + 1 === 0;
var foo = a && (b < 0 || c > 0 || d + 1 === 0);
var foo = a + (b * c);
var foo = (a + b) * c;
Options
{
"no-mixed-operators": [
"error",
{
"groups": [
["+", "-", "*", "/", "%", "**"],
["&", "|", "^", "~", "<<", ">>", ">>>"],
["==", "!=", "===", "!==", ">", ">=", "<", "<="],
["&&", "||"],
["in", "instanceof"]
],
"allowSamePrecedence": true
}
]
}
This rule has 2 options.
-
groups
(string[][]
) - specifies groups to compare operators. When this rule compares two operators, if both operators are included in a same group, this rule checks it. Otherwise, this rule ignores it. This value is a list of groups. The group is a list of binary operators. Default is the groups for each kind of operators. -
allowSamePrecedence
(boolean
) - specifies to allow mix of 2 operators if those have the same precedence. Default istrue
.
groups
The following operators can be used in groups
option:
- Arithmetic Operators:
"+"
,"-"
,"*"
,"/"
,"%"
,"**"
- Bitwise Operators:
"&"
,"|"
,"^"
,"~"
,"<<"
,">>"
,">>>"
- Comparison Operators:
"=="
,"!="
,"==="
,"!=="
,">"
,">="
,"<"
,"<="
- Logical Operators:
"&&"
,"||"
- Relational Operators:
"in"
,"instanceof"
Now, considers about {"groups": [["&", "|", "^", "~", "<<", ">>", ">>>"], ["&&", "||"]]}
configure.
This configure has 2 groups: bitwise operators and logical operators.
This rule checks only if both operators are included in a same group.
So, in this case, this rule comes to check between bitwise operators and between logical operators.
This rule ignores other operators.
Examples of incorrect code for this rule with {"groups": [["&", "|", "^", "~", "<<", ">>", ">>>"], ["&&", "||"]]}
option:
/*eslint no-mixed-operators: ["error", {"groups": [["&", "|", "^", "~", "<<", ">>", ">>>"], ["&&", "||"]]}]*/
var foo = a && b < 0 || c > 0 || d + 1 === 0;
var foo = a & b | c;
Examples of correct code for this rule with {"groups": [["&", "|", "^", "~", "<<", ">>", ">>>"], ["&&", "||"]]}
option:
/*eslint no-mixed-operators: ["error", {"groups": [["&", "|", "^", "~", "<<", ">>", ">>>"], ["&&", "||"]]}]*/
var foo = a || b > 0 || c + 1 === 0;
var foo = a && b > 0 && c + 1 === 0;
var foo = (a && b < 0) || c > 0 || d + 1 === 0;
var foo = a && (b < 0 || c > 0 || d + 1 === 0);
var foo = (a & b) | c;
var foo = a & (b | c);
var foo = a + b * c;
var foo = a + (b * c);
var foo = (a + b) * c;
allowSamePrecedence
Examples of correct code for this rule with {"allowSamePrecedence": true}
option:
/*eslint no-mixed-operators: ["error", {"allowSamePrecedence": true}]*/
// + and - have the same precedence.
var foo = a + b - c;
Examples of incorrect code for this rule with {"allowSamePrecedence": false}
option:
/*eslint no-mixed-operators: ["error", {"allowSamePrecedence": false}]*/
// + and - have the same precedence.
var foo = a + b - c;
When Not To Use It
If you don't want to be notified about mixed operators, then it's safe to disable this rule.
Related Rules
- [no-extra-parens](no-extra-parens.md) Source: http://eslint.org/docs/rules/
Unexpected mix of '+' and '*'. Open
expected: (optimistic + 4 * likely + pessimistic) / 6,
- Read upRead up
- Exclude checks
Disallow mixes of different operators (no-mixed-operators)
Enclosing complex expressions by parentheses clarifies the developer's intention, which makes the code more readable. This rule warns when different operators are used consecutively without parentheses in an expression.
var foo = a && b || c || d; /*BAD: Unexpected mix of '&&' and '||'.*/
var foo = (a && b) || c || d; /*GOOD*/
var foo = a && (b || c || d); /*GOOD*/
Rule Details
This rule checks BinaryExpression
and LogicalExpression
.
This rule may conflict with [no-extra-parens](no-extra-parens.md) rule.
If you use both this and [no-extra-parens](no-extra-parens.md) rule together, you need to use the nestedBinaryExpressions
option of [no-extra-parens](no-extra-parens.md) rule.
Examples of incorrect code for this rule:
/*eslint no-mixed-operators: "error"*/
var foo = a && b < 0 || c > 0 || d + 1 === 0;
var foo = a + b * c;
Examples of correct code for this rule:
/*eslint no-mixed-operators: "error"*/
var foo = a || b || c;
var foo = a && b && c;
var foo = (a && b < 0) || c > 0 || d + 1 === 0;
var foo = a && (b < 0 || c > 0 || d + 1 === 0);
var foo = a + (b * c);
var foo = (a + b) * c;
Options
{
"no-mixed-operators": [
"error",
{
"groups": [
["+", "-", "*", "/", "%", "**"],
["&", "|", "^", "~", "<<", ">>", ">>>"],
["==", "!=", "===", "!==", ">", ">=", "<", "<="],
["&&", "||"],
["in", "instanceof"]
],
"allowSamePrecedence": true
}
]
}
This rule has 2 options.
-
groups
(string[][]
) - specifies groups to compare operators. When this rule compares two operators, if both operators are included in a same group, this rule checks it. Otherwise, this rule ignores it. This value is a list of groups. The group is a list of binary operators. Default is the groups for each kind of operators. -
allowSamePrecedence
(boolean
) - specifies to allow mix of 2 operators if those have the same precedence. Default istrue
.
groups
The following operators can be used in groups
option:
- Arithmetic Operators:
"+"
,"-"
,"*"
,"/"
,"%"
,"**"
- Bitwise Operators:
"&"
,"|"
,"^"
,"~"
,"<<"
,">>"
,">>>"
- Comparison Operators:
"=="
,"!="
,"==="
,"!=="
,">"
,">="
,"<"
,"<="
- Logical Operators:
"&&"
,"||"
- Relational Operators:
"in"
,"instanceof"
Now, considers about {"groups": [["&", "|", "^", "~", "<<", ">>", ">>>"], ["&&", "||"]]}
configure.
This configure has 2 groups: bitwise operators and logical operators.
This rule checks only if both operators are included in a same group.
So, in this case, this rule comes to check between bitwise operators and between logical operators.
This rule ignores other operators.
Examples of incorrect code for this rule with {"groups": [["&", "|", "^", "~", "<<", ">>", ">>>"], ["&&", "||"]]}
option:
/*eslint no-mixed-operators: ["error", {"groups": [["&", "|", "^", "~", "<<", ">>", ">>>"], ["&&", "||"]]}]*/
var foo = a && b < 0 || c > 0 || d + 1 === 0;
var foo = a & b | c;
Examples of correct code for this rule with {"groups": [["&", "|", "^", "~", "<<", ">>", ">>>"], ["&&", "||"]]}
option:
/*eslint no-mixed-operators: ["error", {"groups": [["&", "|", "^", "~", "<<", ">>", ">>>"], ["&&", "||"]]}]*/
var foo = a || b > 0 || c + 1 === 0;
var foo = a && b > 0 && c + 1 === 0;
var foo = (a && b < 0) || c > 0 || d + 1 === 0;
var foo = a && (b < 0 || c > 0 || d + 1 === 0);
var foo = (a & b) | c;
var foo = a & (b | c);
var foo = a + b * c;
var foo = a + (b * c);
var foo = (a + b) * c;
allowSamePrecedence
Examples of correct code for this rule with {"allowSamePrecedence": true}
option:
/*eslint no-mixed-operators: ["error", {"allowSamePrecedence": true}]*/
// + and - have the same precedence.
var foo = a + b - c;
Examples of incorrect code for this rule with {"allowSamePrecedence": false}
option:
/*eslint no-mixed-operators: ["error", {"allowSamePrecedence": false}]*/
// + and - have the same precedence.
var foo = a + b - c;
When Not To Use It
If you don't want to be notified about mixed operators, then it's safe to disable this rule.
Related Rules
- [no-extra-parens](no-extra-parens.md) Source: http://eslint.org/docs/rules/
Unexpected dangling '_' in '_criticalValue'. Open
this._criticalValue = this.findCriticalValue(value);
- Read upRead up
- Exclude checks
disallow dangling underscores in identifiers (no-underscore-dangle)
As far as naming conventions for identifiers go, dangling underscores may be the most polarizing in JavaScript. Dangling underscores are underscores at either the beginning or end of an identifier, such as:
var _foo;
There is actually a long history of using dangling underscores to indicate "private" members of objects in JavaScript (though JavaScript doesn't have truly private members, this convention served as a warning). This began with SpiderMonkey adding nonstandard methods such as __defineGetter__()
. The intent with the underscores was to make it obvious that this method was special in some way. Since that time, using a single underscore prefix has become popular as a way to indicate "private" members of objects.
Whether or not you choose to allow dangling underscores in identifiers is purely a convention and has no effect on performance, readability, or complexity. It's purely a preference.
Rule Details
This rule disallows dangling underscores in identifiers.
Examples of incorrect code for this rule:
/*eslint no-underscore-dangle: "error"*/
var foo_;
var __proto__ = {};
foo._bar();
Examples of correct code for this rule:
/*eslint no-underscore-dangle: "error"*/
var _ = require('underscore');
var obj = _.contains(items, item);
obj.__proto__ = {};
var file = __filename;
Options
This rule has an object option:
-
"allow"
allows specified identifiers to have dangling underscores -
"allowAfterThis": false
(default) disallows dangling underscores in members of thethis
object -
"allowAfterSuper": false
(default) disallows dangling underscores in members of thesuper
object
allow
Examples of additional correct code for this rule with the { "allow": ["foo_", "_bar"] }
option:
/*eslint no-underscore-dangle: ["error", { "allow": ["foo_", "_bar"] }]*/
var foo_;
foo._bar();
allowAfterThis
Examples of correct code for this rule with the { "allowAfterThis": true }
option:
/*eslint no-underscore-dangle: ["error", { "allowAfterThis": true }]*/
var a = this.foo_;
this._bar();
allowAfterSuper
Examples of correct code for this rule with the { "allowAfterSuper": true }
option:
/*eslint no-underscore-dangle: ["error", { "allowAfterSuper": true }]*/
var a = super.foo_;
super._bar();
When Not To Use It
If you want to allow dangling underscores in identifiers, then you can safely turn this rule off. Source: http://eslint.org/docs/rules/