Java Coding Guidelines for Reliability
- 37. Do not shadow or obscure identifiers in subscopes
- 38. Do not declare more than one variable per declaration
- 39. Use meaningful symbolic constants to represent literal values in program logic
- 40. Properly encode relationships in constant definitions
- 41. Return an empty array or collection instead of a null value for methods that return an array or collection
- 42. Use exceptions only for exceptional conditions
- 43. Use a try-with-resources statement to safely handle closeable resources
- 44. Do not use assertions to verify the absence of runtime errors
- 45. Use the same type for the second and third operands in conditional expressions
- 46. Do not serialize direct handles to system resources
- 47. Prefer using iterators over enumerations
- 48. Do not use direct buffers for short-lived, infrequently used objects
- 49. Remove short-lived objects from long-lived container objects
This chapter is from the book
This chapter is from the book
This chapter is from the book
ISO/IEC/IEEE 24765:2010, Systems and software engineering—Vocabulary, defines reliability as the ability of a system or component to perform its required functions under stated conditions for a specified period of time [ISO/IEC/IEEE 24765:2010]. ISO/IEC 9126-1:2001, Software engineering—Product quality—Part 1: Quality model, provides a similar definition of reliability as the capability of the software product to maintain a specified level of performance when used under specified conditions [ISO/IEC 9126-1:2001].
Software reliability is an important factor affecting system reliability. It differs from hardware reliability in that it reflects design perfection, rather than manufacturing perfection. Wear or aging does not occur in software. Limitations in reliability are the results of faults in requirements, design, and implementation. Failures resulting from these faults depend on the way the software product is used and the program options selected rather than on elapsed time.
ISO/IEC/IEEE 24765:2010 defines software reliability as the probability that software will not cause the failure of a system for a specified time under specified conditions [ISO/IEC/IEEE 24765:2010]. The probability is a function not only of the inputs to and use of the system, but also of the existence of faults in the software. The inputs to the system determine whether existing faults, if any, are encountered. The high complexity of software is the major contributing factor to software reliability problems.
These guidelines deal with Java language features that can easily be misused by the unwary. The Java language allows a great deal of flexibility in the ways in which it is used, but some of these uses can lead to obscure techniques and code that is difficult to understand and maintain. By following these guidelines, programmers will produce code that is less prone to bugs and runtime failure.
This chapter includes guidelines that
- Help reduce errors, and are consequently important for developing reliable Java code
- Contain specific Java coding recommendations to improve software reliability
37. Do not shadow or obscure identifiers in subscopes
Reuse of identifier names in subscopes leads to obscuration or shadowing. 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 source code maintainers and 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 JLS [JLS 2013],
- 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 one variable rendering another variable inaccessible in a containing scope. One type can also shadow another type.
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 a class name or package name. Similarly, an inner class name should not reuse the name of an outer class or package.
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.
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 class 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;
//...
}
}
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 the instance variable i defined in the MyVector class:
class MyVector {
private int i = 0;
private void doLogic() {
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 only defined in the scope of each for loop block:
class MyVector {
private void doLogic() {
for (int i = 0; i < 10; i++) {/* ... */}
for (int i = 0; i < 20; i++) {/* ... */}
}
}
Applicability
Name reuse makes code more difficult to read and maintain, which can result in security weaknesses. An automated tool can easily detect the reuse of identifiers in containing scopes.
Bibliography
[Bloch 2005] |
Puzzle 67, “All Strung Out” |
[Bloch 2008] |
Item 16, “Prefer Interfaces to Abstract Classes” |
[Conventions 2009] |
§6.3, “Placement” |
[FindBugs 2008] |
DLS, “Dead store to local variable that shadows field” |
[JLS 2013] |
§6.4.1, “Shadowing” |
§6.4.2, “Obscuring” |
|
§7.5.2, “Type-Import-on-Demand Declarations” |