Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Note
titleDeprecated

This rule may be deprecated and replaced by a similar guideline.

06/28/2014 -- Version 1.0

 According to The Java Language Specification (JLS)According to the JLS, §15.7, "Evaluation Order" [JLS 20052015]:

The Java programming language guarantees that the operands of operators appear to be evaluated in a specific evaluation order, namely, from left to right.

§15.7.3, "Evaluation Respects Parentheses and Precedence" adds:

Java programming language implementations must respect the order of evaluation as indicated explicitly by parentheses and implicitly by operator precedence.

...

The programmer in this example incorrectly assumes that the rightmost subexpression is evaluated first because the * operator has a higher precedence than the + operator and because the subexpression is parenthesized. This assumption leads to the incorrect conclusion that number is assigned 0 because of the rightmost number = get() subexpression. Consequently, the test in the left-hand subexpression is expected to reject the unprivileged user because the value of number is below the threshold of 10.

...

Code Block
bgColor#FFcccc
class BadPrecedence {
  public static void main(String[] args) {
    int number = 17;
    int threshold = 10;
    number = (number > threshold ? 0 : -2) 
             + ((31 * ++number) * (number = get()));
    // ... 
    if (number == 0) {
      System.out.println("Access granted");
    } else {
      System.out.println("Denied access"); // number = -2
    }
  }

  public static int get() {
    int number = 0;
    // Assign number to non zerononzero value if authorized, else 0
    return number;
  }
}

...

This noncompliant code example reorders the previous expression so that the left-to-right evaluation order of the operands corresponds with the programmer's intent. Although this code performs as expected, it still represents poor practice by writing to number three times in a single expression.

...

This compliant solution uses equivalent code with no side effects and performs not more than one write per expression. The resulting expression can be reordered without concern for the evaluation order of the component expressions, making the code easier to understand and maintain.

Code Block
bgColor#ccccff
int number = 17;

final int authnum = get();
number = ((31 * (number + 1)) * authnum) + (authnum > threshold[0] ? 0 : -2);


Exceptions

EXP05-J-EX0: The increment and decrement operators (++) and (--) read a numeric variable, and then assign a new value to the variable. These are Although these operators read and modify a value, they are well-understood and are an exception to this rule. This exception does not apply if a value modified by an increment or decrement operator is subsequently read or written.

EXP05-J-EX1: The logical operators conditional-or || and conditional-and && operators have well-understood short-circuit semantics, so expressions involving these operators semantics. Writes followed by subsequent writes or reads do not violate this rule if they occur in different operands of || or &&. Consider the following code example:

Code Block
bgColor#ccccff
public void exampleMethod(InputStream in) {
  int i;
  // SkipProcess onechars char,until process'' nextfound
  while ((i = in.read()) != -1 && i != '\'' && 
         (i = in.read()) != -1 && i != '\'') {
    // ...
  }

}

Although the conditional expression appears to violate this rule, this code is compliant because the subexpressions on either side of the && operator do not violate it. Each subexpression has exactly This rule is not violated by the controlling expression of the while loop because the rule is not violated by any operand to the conditional-and && operators. The subexpressions (i = in.read()) != -1 have one assignment and one side effect (the reading of a character from in).

...

Failure to understand the evaluation order of expressions containing side effects can result in unexpected output.

Rule

Severity

Likelihood

Remediation Cost

Priority

Level

EXP05-J

low

Low

unlikely

Unlikely

medium

Medium

P2

L3

Automated Detection

Detection of all expressions involving both side effects and multiple operator precedence levels is straightforward. Determining the correctness of such uses is infeasible in the general case; heuristic warnings could be useful.

ToolVersionCheckerDescription
Parasoft Jtest

Include Page
Parasoft_V
Parasoft_V

CERT.EXP05.CIDAvoid using increment or decrement operators in nested expressions
PVS-Studio

Include Page
PVS-Studio_V

SonarQube Plugin2.4S881 

...


Related Guidelines

Bibliography

 


...

Image Removed      02. Expressions (EXP)      EXP06-J. Do not use side-effecting expressions in assertionsImage Added Image Added Image Added