...
Both overriding and shadowing differ from hiding, in which 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 but has a different, incompatible method signature.
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.
Code Block | ||
---|---|---|
| ||
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.
Code Block | ||
---|---|---|
| ||
class MyVector { private int val = 1; private void doLogic() { int newValue; //... } } |
Noncompliant Code Example (Variable Shadowing)
This example is noncompliant because the variable i
defined in the scope of the second for
loop block, shadows the definition of i
, which is defined in the scope of the doLogic()
method.
Code Block | ||
---|---|---|
| ||
class MyVector { private void doLogic() { int i = 0; for (i = 0; i < 10; i++) {/* ... */} for (int i = 0; i < 20; i++) {/* ... */} } } |
Compliant Solution (Variable Shadowing)
In this compliant solution, the loop counter i
is defined in the scope of each for
loop block.
Code Block | ||
---|---|---|
| ||
class MyVector { private void doLogic() { 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.
Recommendation | Severity | Likelihood | Remediation Cost | Priority | Level |
---|---|---|---|---|---|
DCL15-J | low | unlikely | medium | P2 | L3 |
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
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="6adb33f2a31bef01-f7c5d839-49a44ee6-bb268ff5-b8cc886a5a040e1dd3154e9f"><ac:plain-text-body><![CDATA[ | [[JLS 2005 | AA. Bibliography#JLS 05]] | [§6.3.2, "Obscured Declarations" | http://java.sun.com/docs/books/jls/third_edition/html/names.html#6.3.2] | ]]></ac:plain-text-body></ac:structured-macro> |
| |||||
| |||||
| |||||
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="3ca117cd3c6fa361-76e59c8e-47b944df-a26aa913-d5ff6147a2a55ab71c9a6d6f"><ac:plain-text-body><![CDATA[ | [[Bloch 2005 | AA. Bibliography#Bloch 05]] | Puzzle 67: All Strung Out | ]]></ac:plain-text-body></ac:structured-macro> | |
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="7652c1eb91520313-3f36f3b7-49c14991-aa66a709-4d09299769a7e510161bd379"><ac:plain-text-body><![CDATA[ | [[Bloch 2008 | AA. Bibliography#Bloch 08]] | Item 16: Prefer interfaces to abstract classes | ]]></ac:plain-text-body></ac:structured-macro> | |
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="270a4fe0dd826995-8ef11a35-45f44c46-8348bfd8-453e12b89c67ad84c3469821"><ac:plain-text-body><![CDATA[ | [[Kabanov 2009 | AA. Bibliography#Kabanov 09]] |
| ]]></ac:plain-text-body></ac:structured-macro> | |
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="71926abb169cadf1-5f2e8a6a-421d4041-985faeec-c1ada6b0af6360f64e84d581"><ac:plain-text-body><![CDATA[ | [[Conventions 2009 | AA. Bibliography#Conventions 09]] | 6.3 Placement | ]]></ac:plain-text-body></ac:structured-macro> | |
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="311fa72fff635476-1bad139c-41b648c6-a7ce8cdd-673d853bb0a027787ebba11f"><ac:plain-text-body><![CDATA[ | [[FindBugs 2008 | AA. Bibliography#FindBugs 08]] |
| ]]></ac:plain-text-body></ac:structured-macro> |
...