DCL15-J. Do not mask identifiers in subscopes

Reuse of names leads to obscuration or shadowing; that is, the names in the current scope mask those defined elsewhere. Name reuse creates ambiguity and burdens code maintenance, especially when code requires access to both the original named entity and the entity with the reused name. The problem is aggravated when the reused name is defined in a different package.

According to the Java Language Specification [[JLS 2005]], Section 6.3.2, "Obscured Declarations"

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.

This implies that a variable can obscure a type or a package, and a type can obscure a package name. Shadowing, on the other hand, refers to masking variables, fields, types, method parameters, labels, and exception handler parameters in a subscope. Both these differ from hiding wherein an accessible member (typically non-private) that should have been inherited by a subclass is replaced by a locally declared subclass member that assumes the same name.

No other variable should share the name of a field if the other variable is in a subscope of the field. A block should not declare a variable with the same name as a variable declared in any block that contains it. Reusing variable names leads to programmer confusion about which variable is being modified. Additionally, if variable names are reused, generally one or both of the variable names are too generic.

Noncompliant Code Example (Field Shadowing)

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

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

Compliant Solution (Field Shadowing)

This compliant solution eliminates shadowing by changing the name of the variable defined in method scope.

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

Exceptions

SCP02-EX1: Reuse of names is permitted for trivial loop counter declarations in the same scope:

for (int i = 0; i < 10; i++) {/* ... */}
for (int i = 0; i < 20; i++) {/* ... */}

Risk Assessment

Name reuse makes code more difficult to read and maintain. This can result in security weaknesses.

Automated Detection

An automated tool can easily detect reuse of names in containing scopes.

Related Guidelines

C Secure Coding Standard: DCL01-C. Do not reuse variable names in subscopes

C++ Secure Coding Standard: DCL01-CPP. Do not reuse variable names in subscopes

Bibliography

[[JLS 2005]] Section 6.3.2 "Obscured Declarations", Section 6.3.1 "Shadowing Declarations", Section 7.5.2 "Type-Import-On_Demand Declaration", Section 14.4.3 "Shadowing of Names by Local Variables"
[[Bloch 2005]] Puzzle 67: All Strung Out
[[Bloch 2008]] Item 16: Prefer interfaces to abstract classes
[[Kabanov 2009]]
[[Conventions 2009]] 6.3 Placement
[[FindBugs 2008]]

MET17-J. Do not increase the accessibility of overridden or hidden methods            OBJ17-J. Do not expose sensitive private members of an outer class from within a nested class