Error Prone

AvoidTrailingComma

Since: PMD 5.1

Priority: High (1)

This rule helps improve code portability due to differences in browser treatment of trailing commas in object or array literals.

This rule is defined by the following XPath expression:

//ObjectLiteral[$allowObjectLiteral = false() and @TrailingComma = true()]
|
//ArrayLiteral[$allowArrayLiteral = false() and @TrailingComma = true()]

Example(s):

function(arg) {
    var obj1 = { a : 1 };   // Ok
    var arr1 = [ 1, 2 ];    // Ok

    var obj2 = { a : 1, };  // Syntax error in some browsers!
    var arr2 = [ 1, 2, ];   // Length 2 or 3 depending on the browser!
}

This rule has the following properties:

Use this rule with the default properties by just referencing it:

<rule ref="category/ecmascript/errorprone.xml/AvoidTrailingComma" />

Use this rule and customize it:

<rule ref="category/ecmascript/errorprone.xml/AvoidTrailingComma">
    <properties>
        <property name="allowObjectLiteral" value="false" />
        <property name="allowArrayLiteral" value="false" />
    </properties>
</rule>

EqualComparison

Since: PMD 5.0

Priority: Medium (3)

Using == in condition may lead to unexpected results, as the variables are automatically casted to be of the same type. The === operator avoids the casting.

This rule is defined by the following XPath expression:

//InfixExpression[
  (@Operator = '==' or @Operator = '!=')
  and
  (KeywordLiteral[@Literal = 'true' or @Literal = 'false'] or NumberLiteral)
]

Example(s):

// Ok
if (someVar === true) {
  ...
}
// Ok
if (someVar !== 3) {
  ...
}
// Bad
if (someVar == true) {
  ...
}
// Bad
if (someVar != 3) {
  ...
}

Use this rule by referencing it:

<rule ref="category/ecmascript/errorprone.xml/EqualComparison" />

InaccurateNumericLiteral

Since: PMD 5.0

Priority: Medium High (2)

The numeric literal will have a different value at runtime, which can happen if you provide too much precision in a floating point number. This may result in numeric calculations being in error.

Numbers in JavaScript are represented by 64bit double-precision floating point numbers internally and that’s why there are some limits to the available precision of the number. See Number.isSafeInteger() and Number.EPSILON.

Note: This rule was named InnaccurateNumericLiteral before PMD 7.4.0.

This rule is defined by the following XPath expression:

//NumberLiteral[@Inaccurate = true()]

Example(s):

var a = 9; // Ok
var b = 999999999999999; // Ok
var c = 999999999999999999999; // Not good
var w = 1.12e-4; // Ok
var x = 1.12; // Ok
var y = 1.1234567890123; // Ok
var z = 1.12345678901234567; // Not good

Use this rule by referencing it:

<rule ref="category/ecmascript/errorprone.xml/InaccurateNumericLiteral" />

InnaccurateNumericLiteral

Deprecated

This rule has been renamed. Use instead: InaccurateNumericLiteral

Deprecated

Since: PMD 5.0

Priority: Medium High (2)

The numeric literal will have a different value at runtime, which can happen if you provide too much precision in a floating point number. This may result in numeric calculations being in error.

Numbers in JavaScript are represented by 64bit double-precision floating point numbers internally and that’s why there are some limits to the available precision of the number. See Number.isSafeInteger() and Number.EPSILON.

Note: This rule was named InnaccurateNumericLiteral before PMD 7.4.0.

This rule is defined by the following XPath expression:

//NumberLiteral[@Inaccurate = true()]

Example(s):

var a = 9; // Ok
var b = 999999999999999; // Ok
var c = 999999999999999999999; // Not good
var w = 1.12e-4; // Ok
var x = 1.12; // Ok
var y = 1.1234567890123; // Ok
var z = 1.12345678901234567; // Not good

Use this rule by referencing it:

<rule ref="category/ecmascript/errorprone.xml/InnaccurateNumericLiteral" />