weexteam/weex_devtools_android

View on GitHub

Showing 2,519 of 2,519 total issues

Unexpected trailing comma.
Open

              backgroundColor: '#ffffff',

require or disallow trailing commas (comma-dangle)

Trailing commas in object literals are valid according to the ECMAScript 5 (and ECMAScript 3!) spec. However, IE8 (when not in IE8 document mode) and below will throw an error when it encounters trailing commas in JavaScript.

var foo = {
    bar: "baz",
    qux: "quux",
};

Trailing commas simplify adding and removing items to objects and arrays, since only the lines you are modifying must be touched. Another argument in favor of trailing commas is that it improves the clarity of diffs when an item is added or removed from an object or array:

Less clear:

var foo = {
-    bar: "baz",
-    qux: "quux"
+    bar: "baz"
 };

More clear:

var foo = {
     bar: "baz",
-    qux: "quux",
 };

Rule Details

This rule enforces consistent use of trailing commas in object and array literals.

Options

This rule has a string option or an object option:

{
    "comma-dangle": ["error", "never"],
    // or
    "comma-dangle": ["error", {
        "arrays": "never",
        "objects": "never",
        "imports": "never",
        "exports": "never",
        "functions": "ignore",
    }]
}
  • "never" (default) disallows trailing commas
  • "always" requires trailing commas
  • "always-multiline" requires trailing commas when the last element or property is in a different line than the closing ] or } and disallows trailing commas when the last element or property is on the same line as the closing ] or }
  • "only-multiline" allows (but does not require) trailing commas when the last element or property is in a different line than the closing ] or } and disallows trailing commas when the last element or property is on the same line as the closing ] or }

Trailing commas in function declarations and function calls are valid syntax since ECMAScript 2017; however, the string option does not check these situations for backwards compatibility.

You can also use an object option to configure this rule for each type of syntax. Each of the following options can be set to "never", "always", "always-multiline", "only-multiline", or "ignore". The default for each option is "never" unless otherwise specified.

  • arrays is for array literals and array patterns of destructuring. (e.g. let [a,] = [1,];)
  • objects is for object literals and object patterns of destructuring. (e.g. let {a,} = {a: 1};)
  • imports is for import declarations of ES Modules. (e.g. import {a,} from "foo";)
  • exports is for export declarations of ES Modules. (e.g. export {a,};)
  • functions is for function declarations and function calls. (e.g. (function(a,){ })(b,);)
    functions is set to "ignore" by default for consistency with the string option.

never

Examples of incorrect code for this rule with the default "never" option:

/*eslint comma-dangle: ["error", "never"]*/

var foo = {
    bar: "baz",
    qux: "quux",
};

var arr = [1,2,];

foo({
  bar: "baz",
  qux: "quux",
});

Examples of correct code for this rule with the default "never" option:

/*eslint comma-dangle: ["error", "never"]*/

var foo = {
    bar: "baz",
    qux: "quux"
};

var arr = [1,2];

foo({
  bar: "baz",
  qux: "quux"
});

always

Examples of incorrect code for this rule with the "always" option:

/*eslint comma-dangle: ["error", "always"]*/

var foo = {
    bar: "baz",
    qux: "quux"
};

var arr = [1,2];

foo({
  bar: "baz",
  qux: "quux"
});

Examples of correct code for this rule with the "always" option:

/*eslint comma-dangle: ["error", "always"]*/

var foo = {
    bar: "baz",
    qux: "quux",
};

var arr = [1,2,];

foo({
  bar: "baz",
  qux: "quux",
});

always-multiline

Examples of incorrect code for this rule with the "always-multiline" option:

/*eslint comma-dangle: ["error", "always-multiline"]*/

var foo = {
    bar: "baz",
    qux: "quux"
};

var foo = { bar: "baz", qux: "quux", };

var arr = [1,2,];

var arr = [1,
    2,];

var arr = [
    1,
    2
];

foo({
  bar: "baz",
  qux: "quux"
});

Examples of correct code for this rule with the "always-multiline" option:

/*eslint comma-dangle: ["error", "always-multiline"]*/

var foo = {
    bar: "baz",
    qux: "quux",
};

var foo = {bar: "baz", qux: "quux"};
var arr = [1,2];

var arr = [1,
    2];

var arr = [
    1,
    2,
];

foo({
  bar: "baz",
  qux: "quux",
});

only-multiline

Examples of incorrect code for this rule with the "only-multiline" option:

/*eslint comma-dangle: ["error", "only-multiline"]*/

var foo = { bar: "baz", qux: "quux", };

var arr = [1,2,];

var arr = [1,
    2,];

Examples of correct code for this rule with the "only-multiline" option:

/*eslint comma-dangle: ["error", "only-multiline"]*/

var foo = {
    bar: "baz",
    qux: "quux",
};

var foo = {
    bar: "baz",
    qux: "quux"
};

var foo = {bar: "baz", qux: "quux"};
var arr = [1,2];

var arr = [1,
    2];

var arr = [
    1,
    2,
];

var arr = [
    1,
    2
];

foo({
  bar: "baz",
  qux: "quux",
});

foo({
  bar: "baz",
  qux: "quux"
});

functions

Examples of incorrect code for this rule with the {"functions": "never"} option:

/*eslint comma-dangle: ["error", {"functions": "never"}]*/

function foo(a, b,) {
}

foo(a, b,);
new foo(a, b,);

Examples of correct code for this rule with the {"functions": "never"} option:

/*eslint comma-dangle: ["error", {"functions": "never"}]*/

function foo(a, b) {
}

foo(a, b);
new foo(a, b);

Examples of incorrect code for this rule with the {"functions": "always"} option:

/*eslint comma-dangle: ["error", {"functions": "always"}]*/

function foo(a, b) {
}

foo(a, b);
new foo(a, b);

Examples of correct code for this rule with the {"functions": "always"} option:

/*eslint comma-dangle: ["error", {"functions": "always"}]*/

function foo(a, b,) {
}

foo(a, b,);
new foo(a, b,);

When Not To Use It

You can turn this rule off if you are not concerned with dangling commas. Source: http://eslint.org/docs/rules/

Unnecessary semicolon.
Open

    ;

disallow unnecessary semicolons (no-extra-semi)

Typing mistakes and misunderstandings about where semicolons are required can lead to semicolons that are unnecessary. While not technically an error, extra semicolons can cause confusion when reading code.

Rule Details

This rule disallows unnecessary semicolons.

Examples of incorrect code for this rule:

/*eslint no-extra-semi: "error"*/

var x = 5;;

function foo() {
    // code
};

Examples of correct code for this rule:

/*eslint no-extra-semi: "error"*/

var x = 5;

var foo = function() {
    // code
};

When Not To Use It

If you intentionally use extra semicolons then you can disable this rule.

Related Rules

Unnecessary semicolon.
Open

    ;__weex_define__("@weex-component/style-box", [], function(__weex_require__, __weex_exports__, __weex_module__){

disallow unnecessary semicolons (no-extra-semi)

Typing mistakes and misunderstandings about where semicolons are required can lead to semicolons that are unnecessary. While not technically an error, extra semicolons can cause confusion when reading code.

Rule Details

This rule disallows unnecessary semicolons.

Examples of incorrect code for this rule:

/*eslint no-extra-semi: "error"*/

var x = 5;;

function foo() {
    // code
};

Examples of correct code for this rule:

/*eslint no-extra-semi: "error"*/

var x = 5;

var foo = function() {
    // code
};

When Not To Use It

If you intentionally use extra semicolons then you can disable this rule.

Related Rules

Expected '===' and instead saw '=='.
Open

                    if(i == index){

Require === and !== (eqeqeq)

It is considered good practice to use the type-safe equality operators === and !== instead of their regular counterparts == and !=.

The reason for this is that == and != do type coercion which follows the rather obscure Abstract Equality Comparison Algorithm. For instance, the following statements are all considered true:

  • [] == false
  • [] == ![]
  • 3 == "03"

If one of those occurs in an innocent-looking statement such as a == b the actual problem is very difficult to spot.

Rule Details

This rule is aimed at eliminating the type-unsafe equality operators.

Examples of incorrect code for this rule:

/*eslint eqeqeq: "error"*/

if (x == 42) { }

if ("" == text) { }

if (obj.getStuff() != undefined) { }

The --fix option on the command line automatically fixes some problems reported by this rule. A problem is only fixed if one of the operands is a typeof expression, or if both operands are literals with the same type.

Options

always

The "always" option (default) enforces the use of === and !== in every situation (except when you opt-in to more specific handling of null [see below]).

Examples of incorrect code for the "always" option:

/*eslint eqeqeq: ["error", "always"]*/

a == b
foo == true
bananas != 1
value == undefined
typeof foo == 'undefined'
'hello' != 'world'
0 == 0
true == true
foo == null

Examples of correct code for the "always" option:

/*eslint eqeqeq: ["error", "always"]*/

a === b
foo === true
bananas !== 1
value === undefined
typeof foo === 'undefined'
'hello' !== 'world'
0 === 0
true === true
foo === null

This rule optionally takes a second argument, which should be an object with the following supported properties:

  • "null": Customize how this rule treats null literals. Possible values:
    • always (default) - Always use === or !==.
    • never - Never use === or !== with null.
    • ignore - Do not apply this rule to null.

smart

The "smart" option enforces the use of === and !== except for these cases:

  • Comparing two literal values
  • Evaluating the value of typeof
  • Comparing against null

Examples of incorrect code for the "smart" option:

/*eslint eqeqeq: ["error", "smart"]*/

// comparing two variables requires ===
a == b

// only one side is a literal
foo == true
bananas != 1

// comparing to undefined requires ===
value == undefined

Examples of correct code for the "smart" option:

/*eslint eqeqeq: ["error", "smart"]*/

typeof foo == 'undefined'
'hello' != 'world'
0 == 0
true == true
foo == null

allow-null

Deprecated: Instead of using this option use "always" and pass a "null" option property with value "ignore". This will tell eslint to always enforce strict equality except when comparing with the null literal.

["error", "always", {"null": "ignore"}]

When Not To Use It

If you don't want to enforce a style for using equality operators, then it's safe to disable this rule. Source: http://eslint.org/docs/rules/

Missing radix parameter.
Open

                this.time.m = String(parseInt((remain - parseInt(this.time.H) * 3600) / 60));

Require Radix Parameter (radix)

When using the parseInt() function it is common to omit the second argument, the radix, and let the function try to determine from the first argument what type of number it is. By default, parseInt() will autodetect decimal and hexadecimal (via 0x prefix). Prior to ECMAScript 5, parseInt() also autodetected octal literals, which caused problems because many developers assumed a leading 0 would be ignored.

This confusion led to the suggestion that you always use the radix parameter to parseInt() to eliminate unintended consequences. So instead of doing this:

var num = parseInt("071");      // 57

Do this:

var num = parseInt("071", 10);  // 71

ECMAScript 5 changed the behavior of parseInt() so that it no longer autodetects octal literals and instead treats them as decimal literals. However, the differences between hexadecimal and decimal interpretation of the first parameter causes many developers to continue using the radix parameter to ensure the string is interpreted in the intended way.

On the other hand, if the code is targeting only ES5-compliant environments passing the radix 10 may be redundant. In such a case you might want to disallow using such a radix.

Rule Details

This rule is aimed at preventing the unintended conversion of a string to a number of a different base than intended or at preventing the redundant 10 radix if targeting modern environments only.

Options

There are two options for this rule:

  • "always" enforces providing a radix (default)
  • "as-needed" disallows providing the 10 radix

always

Examples of incorrect code for the default "always" option:

/*eslint radix: "error"*/

var num = parseInt("071");

var num = parseInt(someValue);

var num = parseInt("071", "abc");

var num = parseInt();

Examples of correct code for the default "always" option:

/*eslint radix: "error"*/

var num = parseInt("071", 10);

var num = parseInt("071", 8);

var num = parseFloat(someValue);

as-needed

Examples of incorrect code for the "as-needed" option:

/*eslint radix: ["error", "as-needed"]*/

var num = parseInt("071", 10);

var num = parseInt("071", "abc");

var num = parseInt();

Examples of correct code for the "as-needed" option:

/*eslint radix: ["error", "as-needed"]*/

var num = parseInt("071");

var num = parseInt("071", 8);

var num = parseFloat(someValue);

When Not To Use It

If you don't want to enforce either presence or omission of the 10 radix value you can turn this rule off.

Further Reading

Unexpected trailing comma.
Open

                },  

require or disallow trailing commas (comma-dangle)

Trailing commas in object literals are valid according to the ECMAScript 5 (and ECMAScript 3!) spec. However, IE8 (when not in IE8 document mode) and below will throw an error when it encounters trailing commas in JavaScript.

var foo = {
    bar: "baz",
    qux: "quux",
};

Trailing commas simplify adding and removing items to objects and arrays, since only the lines you are modifying must be touched. Another argument in favor of trailing commas is that it improves the clarity of diffs when an item is added or removed from an object or array:

Less clear:

var foo = {
-    bar: "baz",
-    qux: "quux"
+    bar: "baz"
 };

More clear:

var foo = {
     bar: "baz",
-    qux: "quux",
 };

Rule Details

This rule enforces consistent use of trailing commas in object and array literals.

Options

This rule has a string option or an object option:

{
    "comma-dangle": ["error", "never"],
    // or
    "comma-dangle": ["error", {
        "arrays": "never",
        "objects": "never",
        "imports": "never",
        "exports": "never",
        "functions": "ignore",
    }]
}
  • "never" (default) disallows trailing commas
  • "always" requires trailing commas
  • "always-multiline" requires trailing commas when the last element or property is in a different line than the closing ] or } and disallows trailing commas when the last element or property is on the same line as the closing ] or }
  • "only-multiline" allows (but does not require) trailing commas when the last element or property is in a different line than the closing ] or } and disallows trailing commas when the last element or property is on the same line as the closing ] or }

Trailing commas in function declarations and function calls are valid syntax since ECMAScript 2017; however, the string option does not check these situations for backwards compatibility.

You can also use an object option to configure this rule for each type of syntax. Each of the following options can be set to "never", "always", "always-multiline", "only-multiline", or "ignore". The default for each option is "never" unless otherwise specified.

  • arrays is for array literals and array patterns of destructuring. (e.g. let [a,] = [1,];)
  • objects is for object literals and object patterns of destructuring. (e.g. let {a,} = {a: 1};)
  • imports is for import declarations of ES Modules. (e.g. import {a,} from "foo";)
  • exports is for export declarations of ES Modules. (e.g. export {a,};)
  • functions is for function declarations and function calls. (e.g. (function(a,){ })(b,);)
    functions is set to "ignore" by default for consistency with the string option.

never

Examples of incorrect code for this rule with the default "never" option:

/*eslint comma-dangle: ["error", "never"]*/

var foo = {
    bar: "baz",
    qux: "quux",
};

var arr = [1,2,];

foo({
  bar: "baz",
  qux: "quux",
});

Examples of correct code for this rule with the default "never" option:

/*eslint comma-dangle: ["error", "never"]*/

var foo = {
    bar: "baz",
    qux: "quux"
};

var arr = [1,2];

foo({
  bar: "baz",
  qux: "quux"
});

always

Examples of incorrect code for this rule with the "always" option:

/*eslint comma-dangle: ["error", "always"]*/

var foo = {
    bar: "baz",
    qux: "quux"
};

var arr = [1,2];

foo({
  bar: "baz",
  qux: "quux"
});

Examples of correct code for this rule with the "always" option:

/*eslint comma-dangle: ["error", "always"]*/

var foo = {
    bar: "baz",
    qux: "quux",
};

var arr = [1,2,];

foo({
  bar: "baz",
  qux: "quux",
});

always-multiline

Examples of incorrect code for this rule with the "always-multiline" option:

/*eslint comma-dangle: ["error", "always-multiline"]*/

var foo = {
    bar: "baz",
    qux: "quux"
};

var foo = { bar: "baz", qux: "quux", };

var arr = [1,2,];

var arr = [1,
    2,];

var arr = [
    1,
    2
];

foo({
  bar: "baz",
  qux: "quux"
});

Examples of correct code for this rule with the "always-multiline" option:

/*eslint comma-dangle: ["error", "always-multiline"]*/

var foo = {
    bar: "baz",
    qux: "quux",
};

var foo = {bar: "baz", qux: "quux"};
var arr = [1,2];

var arr = [1,
    2];

var arr = [
    1,
    2,
];

foo({
  bar: "baz",
  qux: "quux",
});

only-multiline

Examples of incorrect code for this rule with the "only-multiline" option:

/*eslint comma-dangle: ["error", "only-multiline"]*/

var foo = { bar: "baz", qux: "quux", };

var arr = [1,2,];

var arr = [1,
    2,];

Examples of correct code for this rule with the "only-multiline" option:

/*eslint comma-dangle: ["error", "only-multiline"]*/

var foo = {
    bar: "baz",
    qux: "quux",
};

var foo = {
    bar: "baz",
    qux: "quux"
};

var foo = {bar: "baz", qux: "quux"};
var arr = [1,2];

var arr = [1,
    2];

var arr = [
    1,
    2,
];

var arr = [
    1,
    2
];

foo({
  bar: "baz",
  qux: "quux",
});

foo({
  bar: "baz",
  qux: "quux"
});

functions

Examples of incorrect code for this rule with the {"functions": "never"} option:

/*eslint comma-dangle: ["error", {"functions": "never"}]*/

function foo(a, b,) {
}

foo(a, b,);
new foo(a, b,);

Examples of correct code for this rule with the {"functions": "never"} option:

/*eslint comma-dangle: ["error", {"functions": "never"}]*/

function foo(a, b) {
}

foo(a, b);
new foo(a, b);

Examples of incorrect code for this rule with the {"functions": "always"} option:

/*eslint comma-dangle: ["error", {"functions": "always"}]*/

function foo(a, b) {
}

foo(a, b);
new foo(a, b);

Examples of correct code for this rule with the {"functions": "always"} option:

/*eslint comma-dangle: ["error", {"functions": "always"}]*/

function foo(a, b,) {
}

foo(a, b,);
new foo(a, b,);

When Not To Use It

You can turn this rule off if you are not concerned with dangling commas. Source: http://eslint.org/docs/rules/

Unnecessary semicolon.
Open

    ;

disallow unnecessary semicolons (no-extra-semi)

Typing mistakes and misunderstandings about where semicolons are required can lead to semicolons that are unnecessary. While not technically an error, extra semicolons can cause confusion when reading code.

Rule Details

This rule disallows unnecessary semicolons.

Examples of incorrect code for this rule:

/*eslint no-extra-semi: "error"*/

var x = 5;;

function foo() {
    // code
};

Examples of correct code for this rule:

/*eslint no-extra-semi: "error"*/

var x = 5;

var foo = function() {
    // code
};

When Not To Use It

If you intentionally use extra semicolons then you can disable this rule.

Related Rules

Missing radix parameter.
Open

                this.time.s = String(remain - parseInt(this.time.M) * 60);

Require Radix Parameter (radix)

When using the parseInt() function it is common to omit the second argument, the radix, and let the function try to determine from the first argument what type of number it is. By default, parseInt() will autodetect decimal and hexadecimal (via 0x prefix). Prior to ECMAScript 5, parseInt() also autodetected octal literals, which caused problems because many developers assumed a leading 0 would be ignored.

This confusion led to the suggestion that you always use the radix parameter to parseInt() to eliminate unintended consequences. So instead of doing this:

var num = parseInt("071");      // 57

Do this:

var num = parseInt("071", 10);  // 71

ECMAScript 5 changed the behavior of parseInt() so that it no longer autodetects octal literals and instead treats them as decimal literals. However, the differences between hexadecimal and decimal interpretation of the first parameter causes many developers to continue using the radix parameter to ensure the string is interpreted in the intended way.

On the other hand, if the code is targeting only ES5-compliant environments passing the radix 10 may be redundant. In such a case you might want to disallow using such a radix.

Rule Details

This rule is aimed at preventing the unintended conversion of a string to a number of a different base than intended or at preventing the redundant 10 radix if targeting modern environments only.

Options

There are two options for this rule:

  • "always" enforces providing a radix (default)
  • "as-needed" disallows providing the 10 radix

always

Examples of incorrect code for the default "always" option:

/*eslint radix: "error"*/

var num = parseInt("071");

var num = parseInt(someValue);

var num = parseInt("071", "abc");

var num = parseInt();

Examples of correct code for the default "always" option:

/*eslint radix: "error"*/

var num = parseInt("071", 10);

var num = parseInt("071", 8);

var num = parseFloat(someValue);

as-needed

Examples of incorrect code for the "as-needed" option:

/*eslint radix: ["error", "as-needed"]*/

var num = parseInt("071", 10);

var num = parseInt("071", "abc");

var num = parseInt();

Examples of correct code for the "as-needed" option:

/*eslint radix: ["error", "as-needed"]*/

var num = parseInt("071");

var num = parseInt("071", 8);

var num = parseFloat(someValue);

When Not To Use It

If you don't want to enforce either presence or omission of the 10 radix value you can turn this rule off.

Further Reading

Unnecessary semicolon.
Open

    ;

disallow unnecessary semicolons (no-extra-semi)

Typing mistakes and misunderstandings about where semicolons are required can lead to semicolons that are unnecessary. While not technically an error, extra semicolons can cause confusion when reading code.

Rule Details

This rule disallows unnecessary semicolons.

Examples of incorrect code for this rule:

/*eslint no-extra-semi: "error"*/

var x = 5;;

function foo() {
    // code
};

Examples of correct code for this rule:

/*eslint no-extra-semi: "error"*/

var x = 5;

var foo = function() {
    // code
};

When Not To Use It

If you intentionally use extra semicolons then you can disable this rule.

Related Rules

Expected an assignment or function call and instead saw an expression.
Open

                    cb && cb();

Disallow Unused Expressions (no-unused-expressions)

An unused expression which has no effect on the state of the program indicates a logic error.

For example, n + 1; is not a syntax error, but it might be a typing mistake where a programmer meant an assignment statement n += 1; instead.

Rule Details

This rule aims to eliminate unused expressions which have no effect on the state of the program.

This rule does not apply to function calls or constructor calls with the new operator, because they could have side effects on the state of the program.

var i = 0;
function increment() { i += 1; }
increment(); // return value is unused, but i changed as a side effect

var nThings = 0;
function Thing() { nThings += 1; }
new Thing(); // constructed object is unused, but nThings changed as a side effect

This rule does not apply to directives (which are in the form of literal string expressions such as "use strict"; at the beginning of a script, module, or function).

Sequence expressions (those using a comma, such as a = 1, b = 2) are always considered unused unless their return value is assigned or used in a condition evaluation, or a function call is made with the sequence expression value.

Options

This rule, in its default state, does not require any arguments. If you would like to enable one or more of the following you may pass an object with the options set as follows:

  • allowShortCircuit set to true will allow you to use short circuit evaluations in your expressions (Default: false).
  • allowTernary set to true will enable you to use ternary operators in your expressions similarly to short circuit evaluations (Default: false).
  • allowTaggedTemplates set to true will enable you to use tagged template literals in your expressions (Default: false).

These options allow unused expressions only if all of the code paths either directly change the state (for example, assignment statement) or could have side effects (for example, function call).

Examples of incorrect code for the default { "allowShortCircuit": false, "allowTernary": false } options:

/*eslint no-unused-expressions: "error"*/

0

if(0) 0

{0}

f(0), {}

a && b()

a, b()

c = a, b;

a() && function namedFunctionInExpressionContext () {f();}

(function anIncompleteIIFE () {});

injectGlobal`body{ color: red; }`

Note that one or more string expression statements (with or without semi-colons) will only be considered as unused if they are not in the beginning of a script, module, or function (alone and uninterrupted by other statements). Otherwise, they will be treated as part of a "directive prologue", a section potentially usable by JavaScript engines. This includes "strict mode" directives.

"use strict";
"use asm"
"use stricter";
"use babel"
"any other strings like this in the prologue";

Examples of correct code for the default { "allowShortCircuit": false, "allowTernary": false } options:

/*eslint no-unused-expressions: "error"*/

{} // In this context, this is a block statement, not an object literal

{myLabel: someVar} // In this context, this is a block statement with a label and expression, not an object literal

function namedFunctionDeclaration () {}

(function aGenuineIIFE () {}());

f()

a = 0

new C

delete a.b

void a

allowShortCircuit

Examples of incorrect code for the { "allowShortCircuit": true } option:

/*eslint no-unused-expressions: ["error", { "allowShortCircuit": true }]*/

a || b

Examples of correct code for the { "allowShortCircuit": true } option:

/*eslint no-unused-expressions: ["error", { "allowShortCircuit": true }]*/

a && b()
a() || (b = c)

allowTernary

Examples of incorrect code for the { "allowTernary": true } option:

/*eslint no-unused-expressions: ["error", { "allowTernary": true }]*/

a ? b : 0
a ? b : c()

Examples of correct code for the { "allowTernary": true } option:

/*eslint no-unused-expressions: ["error", { "allowTernary": true }]*/

a ? b() : c()
a ? (b = c) : d()

allowShortCircuit and allowTernary

Examples of correct code for the { "allowShortCircuit": true, "allowTernary": true } options:

/*eslint no-unused-expressions: ["error", { "allowShortCircuit": true, "allowTernary": true }]*/

a ? b() || (c = d) : e()

allowTaggedTemplates

Examples of incorrect code for the { "allowTaggedTemplates": true } option:

/*eslint no-unused-expressions: ["error", { "allowTaggedTemplates": true }]*/

`some untagged template string`;

Examples of correct code for the { "allowTaggedTemplates": true } option:

/*eslint no-unused-expressions: ["error", { "allowTaggedTemplates": true }]*/

tag`some tagged template string`;

Source: http://eslint.org/docs/rules/

Missing radix parameter.
Open

                this.time.H = String(parseInt(remain / 3600));

Require Radix Parameter (radix)

When using the parseInt() function it is common to omit the second argument, the radix, and let the function try to determine from the first argument what type of number it is. By default, parseInt() will autodetect decimal and hexadecimal (via 0x prefix). Prior to ECMAScript 5, parseInt() also autodetected octal literals, which caused problems because many developers assumed a leading 0 would be ignored.

This confusion led to the suggestion that you always use the radix parameter to parseInt() to eliminate unintended consequences. So instead of doing this:

var num = parseInt("071");      // 57

Do this:

var num = parseInt("071", 10);  // 71

ECMAScript 5 changed the behavior of parseInt() so that it no longer autodetects octal literals and instead treats them as decimal literals. However, the differences between hexadecimal and decimal interpretation of the first parameter causes many developers to continue using the radix parameter to ensure the string is interpreted in the intended way.

On the other hand, if the code is targeting only ES5-compliant environments passing the radix 10 may be redundant. In such a case you might want to disallow using such a radix.

Rule Details

This rule is aimed at preventing the unintended conversion of a string to a number of a different base than intended or at preventing the redundant 10 radix if targeting modern environments only.

Options

There are two options for this rule:

  • "always" enforces providing a radix (default)
  • "as-needed" disallows providing the 10 radix

always

Examples of incorrect code for the default "always" option:

/*eslint radix: "error"*/

var num = parseInt("071");

var num = parseInt(someValue);

var num = parseInt("071", "abc");

var num = parseInt();

Examples of correct code for the default "always" option:

/*eslint radix: "error"*/

var num = parseInt("071", 10);

var num = parseInt("071", 8);

var num = parseFloat(someValue);

as-needed

Examples of incorrect code for the "as-needed" option:

/*eslint radix: ["error", "as-needed"]*/

var num = parseInt("071", 10);

var num = parseInt("071", "abc");

var num = parseInt();

Examples of correct code for the "as-needed" option:

/*eslint radix: ["error", "as-needed"]*/

var num = parseInt("071");

var num = parseInt("071", 8);

var num = parseFloat(someValue);

When Not To Use It

If you don't want to enforce either presence or omission of the 10 radix value you can turn this rule off.

Further Reading

Unnecessary semicolon.
Open

    ;

disallow unnecessary semicolons (no-extra-semi)

Typing mistakes and misunderstandings about where semicolons are required can lead to semicolons that are unnecessary. While not technically an error, extra semicolons can cause confusion when reading code.

Rule Details

This rule disallows unnecessary semicolons.

Examples of incorrect code for this rule:

/*eslint no-extra-semi: "error"*/

var x = 5;;

function foo() {
    // code
};

Examples of correct code for this rule:

/*eslint no-extra-semi: "error"*/

var x = 5;

var foo = function() {
    // code
};

When Not To Use It

If you intentionally use extra semicolons then you can disable this rule.

Related Rules

Unnecessary semicolon.
Open

    ;__weex_define__("@weex-component/wxc-navpage", [], function(__weex_require__, __weex_exports__, __weex_module__){

disallow unnecessary semicolons (no-extra-semi)

Typing mistakes and misunderstandings about where semicolons are required can lead to semicolons that are unnecessary. While not technically an error, extra semicolons can cause confusion when reading code.

Rule Details

This rule disallows unnecessary semicolons.

Examples of incorrect code for this rule:

/*eslint no-extra-semi: "error"*/

var x = 5;;

function foo() {
    // code
};

Examples of correct code for this rule:

/*eslint no-extra-semi: "error"*/

var x = 5;

var foo = function() {
    // code
};

When Not To Use It

If you intentionally use extra semicolons then you can disable this rule.

Related Rules

Unnecessary semicolon.
Open

    ;__weex_define__("@weex-component/7978f07b05c68b28c52fc988cc1e3560", [], function(__weex_require__, __weex_exports__, __weex_module__){

disallow unnecessary semicolons (no-extra-semi)

Typing mistakes and misunderstandings about where semicolons are required can lead to semicolons that are unnecessary. While not technically an error, extra semicolons can cause confusion when reading code.

Rule Details

This rule disallows unnecessary semicolons.

Examples of incorrect code for this rule:

/*eslint no-extra-semi: "error"*/

var x = 5;;

function foo() {
    // code
};

Examples of correct code for this rule:

/*eslint no-extra-semi: "error"*/

var x = 5;

var foo = function() {
    // code
};

When Not To Use It

If you intentionally use extra semicolons then you can disable this rule.

Related Rules

Unnecessary semicolon.
Open

    ;__weex_module__.exports.template = __weex_module__.exports.template || {}

disallow unnecessary semicolons (no-extra-semi)

Typing mistakes and misunderstandings about where semicolons are required can lead to semicolons that are unnecessary. While not technically an error, extra semicolons can cause confusion when reading code.

Rule Details

This rule disallows unnecessary semicolons.

Examples of incorrect code for this rule:

/*eslint no-extra-semi: "error"*/

var x = 5;;

function foo() {
    // code
};

Examples of correct code for this rule:

/*eslint no-extra-semi: "error"*/

var x = 5;

var foo = function() {
    // code
};

When Not To Use It

If you intentionally use extra semicolons then you can disable this rule.

Related Rules

Unnecessary semicolon.
Open

    ;

disallow unnecessary semicolons (no-extra-semi)

Typing mistakes and misunderstandings about where semicolons are required can lead to semicolons that are unnecessary. While not technically an error, extra semicolons can cause confusion when reading code.

Rule Details

This rule disallows unnecessary semicolons.

Examples of incorrect code for this rule:

/*eslint no-extra-semi: "error"*/

var x = 5;;

function foo() {
    // code
};

Examples of correct code for this rule:

/*eslint no-extra-semi: "error"*/

var x = 5;

var foo = function() {
    // code
};

When Not To Use It

If you intentionally use extra semicolons then you can disable this rule.

Related Rules

Expected '===' and instead saw '=='.
Open

            return this.type == '1' ? '#7BA3A8' : '#BEAD92';

Require === and !== (eqeqeq)

It is considered good practice to use the type-safe equality operators === and !== instead of their regular counterparts == and !=.

The reason for this is that == and != do type coercion which follows the rather obscure Abstract Equality Comparison Algorithm. For instance, the following statements are all considered true:

  • [] == false
  • [] == ![]
  • 3 == "03"

If one of those occurs in an innocent-looking statement such as a == b the actual problem is very difficult to spot.

Rule Details

This rule is aimed at eliminating the type-unsafe equality operators.

Examples of incorrect code for this rule:

/*eslint eqeqeq: "error"*/

if (x == 42) { }

if ("" == text) { }

if (obj.getStuff() != undefined) { }

The --fix option on the command line automatically fixes some problems reported by this rule. A problem is only fixed if one of the operands is a typeof expression, or if both operands are literals with the same type.

Options

always

The "always" option (default) enforces the use of === and !== in every situation (except when you opt-in to more specific handling of null [see below]).

Examples of incorrect code for the "always" option:

/*eslint eqeqeq: ["error", "always"]*/

a == b
foo == true
bananas != 1
value == undefined
typeof foo == 'undefined'
'hello' != 'world'
0 == 0
true == true
foo == null

Examples of correct code for the "always" option:

/*eslint eqeqeq: ["error", "always"]*/

a === b
foo === true
bananas !== 1
value === undefined
typeof foo === 'undefined'
'hello' !== 'world'
0 === 0
true === true
foo === null

This rule optionally takes a second argument, which should be an object with the following supported properties:

  • "null": Customize how this rule treats null literals. Possible values:
    • always (default) - Always use === or !==.
    • never - Never use === or !== with null.
    • ignore - Do not apply this rule to null.

smart

The "smart" option enforces the use of === and !== except for these cases:

  • Comparing two literal values
  • Evaluating the value of typeof
  • Comparing against null

Examples of incorrect code for the "smart" option:

/*eslint eqeqeq: ["error", "smart"]*/

// comparing two variables requires ===
a == b

// only one side is a literal
foo == true
bananas != 1

// comparing to undefined requires ===
value == undefined

Examples of correct code for the "smart" option:

/*eslint eqeqeq: ["error", "smart"]*/

typeof foo == 'undefined'
'hello' != 'world'
0 == 0
true == true
foo == null

allow-null

Deprecated: Instead of using this option use "always" and pass a "null" option property with value "ignore". This will tell eslint to always enforce strict equality except when comparing with the null literal.

["error", "always", {"null": "ignore"}]

When Not To Use It

If you don't want to enforce a style for using equality operators, then it's safe to disable this rule. Source: http://eslint.org/docs/rules/

Unnecessary semicolon.
Open

    ;__weex_module__.exports.template = __weex_module__.exports.template || {}

disallow unnecessary semicolons (no-extra-semi)

Typing mistakes and misunderstandings about where semicolons are required can lead to semicolons that are unnecessary. While not technically an error, extra semicolons can cause confusion when reading code.

Rule Details

This rule disallows unnecessary semicolons.

Examples of incorrect code for this rule:

/*eslint no-extra-semi: "error"*/

var x = 5;;

function foo() {
    // code
};

Examples of correct code for this rule:

/*eslint no-extra-semi: "error"*/

var x = 5;

var foo = function() {
    // code
};

When Not To Use It

If you intentionally use extra semicolons then you can disable this rule.

Related Rules

Unnecessary semicolon.
Open

    ;

disallow unnecessary semicolons (no-extra-semi)

Typing mistakes and misunderstandings about where semicolons are required can lead to semicolons that are unnecessary. While not technically an error, extra semicolons can cause confusion when reading code.

Rule Details

This rule disallows unnecessary semicolons.

Examples of incorrect code for this rule:

/*eslint no-extra-semi: "error"*/

var x = 5;;

function foo() {
    // code
};

Examples of correct code for this rule:

/*eslint no-extra-semi: "error"*/

var x = 5;

var foo = function() {
    // code
};

When Not To Use It

If you intentionally use extra semicolons then you can disable this rule.

Related Rules

Missing radix parameter.
Open

                    this.time.elapse = parseInt((Date.now() - this.now) / 1000);

Require Radix Parameter (radix)

When using the parseInt() function it is common to omit the second argument, the radix, and let the function try to determine from the first argument what type of number it is. By default, parseInt() will autodetect decimal and hexadecimal (via 0x prefix). Prior to ECMAScript 5, parseInt() also autodetected octal literals, which caused problems because many developers assumed a leading 0 would be ignored.

This confusion led to the suggestion that you always use the radix parameter to parseInt() to eliminate unintended consequences. So instead of doing this:

var num = parseInt("071");      // 57

Do this:

var num = parseInt("071", 10);  // 71

ECMAScript 5 changed the behavior of parseInt() so that it no longer autodetects octal literals and instead treats them as decimal literals. However, the differences between hexadecimal and decimal interpretation of the first parameter causes many developers to continue using the radix parameter to ensure the string is interpreted in the intended way.

On the other hand, if the code is targeting only ES5-compliant environments passing the radix 10 may be redundant. In such a case you might want to disallow using such a radix.

Rule Details

This rule is aimed at preventing the unintended conversion of a string to a number of a different base than intended or at preventing the redundant 10 radix if targeting modern environments only.

Options

There are two options for this rule:

  • "always" enforces providing a radix (default)
  • "as-needed" disallows providing the 10 radix

always

Examples of incorrect code for the default "always" option:

/*eslint radix: "error"*/

var num = parseInt("071");

var num = parseInt(someValue);

var num = parseInt("071", "abc");

var num = parseInt();

Examples of correct code for the default "always" option:

/*eslint radix: "error"*/

var num = parseInt("071", 10);

var num = parseInt("071", 8);

var num = parseFloat(someValue);

as-needed

Examples of incorrect code for the "as-needed" option:

/*eslint radix: ["error", "as-needed"]*/

var num = parseInt("071", 10);

var num = parseInt("071", "abc");

var num = parseInt();

Examples of correct code for the "as-needed" option:

/*eslint radix: ["error", "as-needed"]*/

var num = parseInt("071");

var num = parseInt("071", 8);

var num = parseFloat(someValue);

When Not To Use It

If you don't want to enforce either presence or omission of the 10 radix value you can turn this rule off.

Further Reading

Severity
Category
Status
Source
Language