jluchiji/mongo-stash

View on GitHub

Showing 5 of 5 total issues

Unexpected dangling '_' in '_id'.
Open

  stash.emit('cache.set', obj._id);
Severity: Minor
Found in src/cache.js by eslint

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 the this object
  • "allowAfterSuper": false (default) disallows dangling underscores in members of the super 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

    const nanosec = delta[0] * 1e9 + delta[1];
Severity: Minor
Found in src/stat.js by eslint

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 is true.

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

Unexpected dangling '_' in '_id'.
Open

  if (!obj || !obj._id) { return obj; }
Severity: Minor
Found in src/cache.js by eslint

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 the this object
  • "allowAfterSuper": false (default) disallows dangling underscores in members of the super 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 '_id'.
Open

  LruCache.prototype.set.call(this, obj._id.toString(), obj, age);
Severity: Minor
Found in src/cache.js by eslint

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 the this object
  • "allowAfterSuper": false (default) disallows dangling underscores in members of the super 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

    const nanosec = delta[0] * 1e9 + delta[1];
Severity: Minor
Found in src/stat.js by eslint

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 is true.

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

Severity
Category
Status
Source
Language