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){varobj1={a:1};// Okvararr1=[1,2];// Okvarobj2={a:1,};// Syntax error in some browsers!vararr2=[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:

<ruleref="category/ecmascript/errorprone.xml/AvoidTrailingComma"/>

Use this rule and customize it:

<ruleref="category/ecmascript/errorprone.xml/AvoidTrailingComma"><properties><propertyname="allowObjectLiteral"value="false"/><propertyname="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 thesame 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']orNumberLiteral)]

Example(s):

// Okif(someVar===true){...}// Okif(someVar!==3){...}// Badif(someVar==true){...}// Badif(someVar!=3){...}

Use this rule by referencing it:

<ruleref="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 muchprecision in a floating point number. This may result in numeric calculations being in error.

Numbers in JavaScriptare represented by 64bit double-precision floating point numbers internally and that’s why there are some limitsto the available precision of the number.SeeNumber.isSafeInteger()andNumber.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):

vara=9;// Okvarb=999999999999999;// Okvarc=999999999999999999999;// Not goodvarw=1.12e-4;// Okvarx=1.12;// Okvary=1.1234567890123;// Okvarz=1.12345678901234567;// Not good

Use this rule by referencing it:

<ruleref="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 muchprecision in a floating point number. This may result in numeric calculations being in error.

Numbers in JavaScriptare represented by 64bit double-precision floating point numbers internally and that’s why there are some limitsto the available precision of the number.SeeNumber.isSafeInteger()andNumber.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):

vara=9;// Okvarb=999999999999999;// Okvarc=999999999999999999999;// Not goodvarw=1.12e-4;// Okvarx=1.12;// Okvary=1.1234567890123;// Okvarz=1.12345678901234567;// Not good

Use this rule by referencing it:

<ruleref="category/ecmascript/errorprone.xml/InnaccurateNumericLiteral"/>