Page History

Reuse of identifier names in subscopes leads to obscuration or shadowing. The reused Reused identifiers in the current scope can render those defined elsewhere inaccessible. Although the Java Language Specification (JLS) [JLS 2013] clearly resolves any syntactic ambiguity arising from obscuring or shadowing, such ambiguity burdens code maintainers and source code auditors, especially when code requires access to both the original named entity and the inaccessible one. The problem is exacerbated when the reused name is defined in a different package.

According to §6.4.2, "Obscuring," of the Java Language Specification JLS [JLS 20112013],

A simple name may occur in contexts where it may potentially be interpreted as the name of a variable, a type, or a package. In these situations, the rules of §6.5 specify that a variable will be chosen in preference to a type, and that a type will be chosen in preference to a package.

...

No identifier should obscure or shadow another identifier in a containing scope. For example, a local variable should not reuse the name of a class field or method or the a class name or package name. Similarly, an inner class name should not reuse the name of an outer class or package.

...

This noncompliant code example reuses the name of the val instance field in the scope of an instance method. The resulting behavior can be classified as shadowing.

class MyVector {
  private int val = 1;
  private void doLogic() {
    int val;
    //...   
  }
}

The resulting behavior can be classified as shadowing; the method variable renders the class variable inaccessible within the scope of the method. For example, assigning to this.val from within the method does not affect the value of the call variable.

Compliant Solution (Field Shadowing)

This compliant solution eliminates shadowing by changing the name of the variable defined in the method scope from val to newValue:

class MyVector {
  private int val = 1;
  private void doLogic() {
    int newValue;
    //...   
  }
}

...

This example is noncompliant because the variable i defined in the scope of the second for loop block shadows the definition of the instance variable i defined in the scope of the doLogic() method MyVector class:

class MyVector {
  private int i = 0;
  private void doLogic() {
    for (i = 0; i < 10; i++) {/* ... */}
    for (int i = 0; i < 20; i++) {/* ... */} 
  }
}

...

Name reuse makes code more difficult to read and maintain, which can result in security weaknesses. An automated tool can easily detect reuse of names identifiers in containing scopes.

Bibliography

...