weexteam/weex_devtools_android

View on GitHub

Showing 2,519 of 2,519 total issues

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-tip", [], 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/wxc-navbar", [], 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

    ;

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-list-item", [], 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

    ;

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

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

    ;__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

Empty block statement.
Open

              else {

disallow empty block statements (no-empty)

Empty block statements, while not technically errors, usually occur due to refactoring that wasn't completed. They can cause confusion when reading code.

Rule Details

This rule disallows empty block statements. This rule ignores block statements which contain a comment (for example, in an empty catch or finally block of a try statement to indicate that execution should continue regardless of errors).

Examples of incorrect code for this rule:

/*eslint no-empty: "error"*/

if (foo) {
}

while (foo) {
}

switch(foo) {
}

try {
    doSomething();
} catch(ex) {

} finally {

}

Examples of correct code for this rule:

/*eslint no-empty: "error"*/

if (foo) {
    // empty
}

while (foo) {
    /* empty */
}

try {
    doSomething();
} catch (ex) {
    // continue regardless of error
}

try {
    doSomething();
} finally {
    /* continue regardless of error */
}

Options

This rule has an object option for exceptions:

  • "allowEmptyCatch": true allows empty catch clauses (that is, which do not contain a comment)

allowEmptyCatch

Examples of additional correct code for this rule with the { "allowEmptyCatch": true } option:

/* eslint no-empty: ["error", { "allowEmptyCatch": true }] */
try {
    doSomething();
} catch (ex) {}

try {
    doSomething();
}
catch (ex) {}
finally {
    /* continue regardless of error */
}

When Not To Use It

If you intentionally use empty block statements then you can disable this rule.

Related Rules

Unnecessary semicolon.
Open

    ;__weex_define__("@weex-component/wxc-button", [], 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

Missing radix parameter.
Open

                this.time.D = String(parseInt(remain / 86400));

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

    ;__weex_define__("@weex-component/wxc-marquee", [], 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

    ;

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

Unnecessary semicolon.
Open

    ;__weex_define__("@weex-component/c4cf89f671d6ea6fd7e10fa90eb398e9", [], 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

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 newline between function and ( of function call.
Open

/******/ ([

disallow confusing multiline expressions (no-unexpected-multiline)

Semicolons are usually optional in JavaScript, because of automatic semicolon insertion (ASI). You can require or disallow semicolons with the [semi](./semi.md) rule.

The rules for ASI are relatively straightforward: As once described by Isaac Schlueter, a newline character always ends a statement, just like a semicolon, except where one of the following is true:

  • The statement has an unclosed paren, array literal, or object literal or ends in some other way that is not a valid way to end a statement. (For instance, ending with . or ,.)
  • The line is -- or ++ (in which case it will decrement/increment the next token.)
  • It is a for(), while(), do, if(), or else, and there is no {
  • The next line starts with [, (, +, *, /, -, ,, ., or some other binary operator that can only be found between two tokens in a single expression.

In the exceptions where a newline does not end a statement, a typing mistake to omit a semicolon causes two unrelated consecutive lines to be interpreted as one expression. Especially for a coding style without semicolons, readers might overlook the mistake. Although syntactically correct, the code might throw exceptions when it is executed.

Rule Details

This rule disallows confusing multiline expressions where a newline looks like it is ending a statement, but is not.

Examples of incorrect code for this rule:

/*eslint no-unexpected-multiline: "error"*/

var foo = bar
(1 || 2).baz();

var hello = 'world'
[1, 2, 3].forEach(addNumber);

let x = function() {}
`hello`

let x = function() {}
x
`hello`

Examples of correct code for this rule:

/*eslint no-unexpected-multiline: "error"*/

var foo = bar;
(1 || 2).baz();

var foo = bar
;(1 || 2).baz()

var hello = 'world';
[1, 2, 3].forEach(addNumber);

var hello = 'world'
void [1, 2, 3].forEach(addNumber);

let x = function() {};
`hello`

let tag = function() {}
tag `hello`

When Not To Use It

You can turn this rule off if you are confident that you will not accidentally introduce code like this.

Note that the patterns considered problems are not flagged by the [semi](semi.md) 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

Severity
Category
Status
Source
Language