Chapter 7. General Programming
Item 29: Minimize the scope of local variablesThe most powerful technique for minimizing the scope of a local variable is to declare it where it is first used.Nearly every local variable declaration should contain an initializer.
Keep methods small and focused.
The for loop allows you to declareloop variables, limiting their scope to the exact region where they're needed. (This region consists of the body of the loop as well as the initialization, test, and update preceding the body.) Therefore prefer for loops to while loops.
for (Iterator i = c.iterator(); i.hasNext(); ) 
{
doSomething(i.next());
}for (int i = 0, n = expensiveComputation(); i < n; i++) {
doSomething(i);
} Again, this idiom uses two loop variables, and the second variable, n, is used to avoid the cost of performing redundant computation on every iteration. As a rule, you should use this idiom if the loop test involves a method invocation and the method invocation is guaranteed to return the same result on each iteration.
Item 30: Know and use the librariesSuppose you want to generate random integers between 0 and some upper bound.
static Random rnd = new Random();
// Common but flawed!
static int random(int n) {
return Math.abs(rnd.nextInt()) % n;
}The method attempts to map the value returned by rnd.nextInt() into a nonnegative integer with Math.abs. If nextInt() returns Integer.MIN_VALUE, Math.abs will also return Integer.MIN_VALUE, and the remainder operator (%) will return a negative number. Use Random.nextInt(int) instead.
By using a standard library, you take advantage of the knowledge of the experts who wrote it and the experience of
those who used it before you.
Numerous features are added to the libraries in every major release, and it pays to keep abreast of these additions.
Every programmer should be familiar with the contents of
java.lang,
java.util, and, to a lesser extent,
java.io.
In the 1.2 release, a
Collections Framework was added to the
java.util package. It should be part of every programmer's basic toolkit.
A third-party library worthy of note is Doug Lea's
util.concurrent, which provides high-level concurrency utilities to simplify the task of multithreaded programming.
There are many additions to the libraries in the 1.4 release. Notable additions include the following:
?
java.util.regex— A full-blown Perl-like regular expression facility.
?
java.util.prefs— A facility for the persistent storage of user preferences and program configuration data.
?
java.nio— A high-performance I/O facility, including scalable I/O (akin to the Unix poll call) and memory-mapped I/O (akin to the Unix mmap call).
?
java.util.LinkedHashSet,
LinkedHashMap,
IdentityHashMap— New collection implementations.
Item 31: Avoid float and double if exact answers are requiredThe float and double types are particularly ill-suited for monetary calculations because it is impossible to represent 0.1 (or any other negative power of ten) as a float or double exactly.For example, suppose you have a dollar in your pocket, and you see a shelf with a row of delicious candies priced at 10, 20, 30, and so forth, up to a dollar.
// Broken - uses floating point for monetary calculation!
public static void main(String[] args) {
double funds = 1.00;
int itemsBought = 0;
for (double price = .10; funds >= price; price += .10) {
funds -= price;
itemsBought++;
}
System.out.println(itemsBought + " items bought.");
System.out.println("Change: $" + funds);
} If you run the program, you'll find that you can afford three pieces of candy, and you have $0.3999999999999999 left. This is the wrong answer! The right way to solve this problem is to use BigDecimal, int, or long for monetary calculations:
public static void main(String[] args) {
final BigDecimal TEN_CENTS = new BigDecimal(".10");
int itemsBought = 0;
BigDecimal funds = new BigDecimal("1.00");
for (BigDecimal price = TEN_CENTS; funds.compareTo(price) >= 0; price = price.add(TEN_CENTS)) {
itemsBought++;
funds = funds.subtract(price);
}
System.out.println(itemsBought + " items bought.");
System.out.println("Money left over: $" + funds);
} An alternative to using BigDecimal is to use int (don't exceed nine decimal digits) or long (don't exceed eighteen digits), depending on the amounts involved, and to keep track of the decimal point yourself:
public static void main(String[] args) {
int itemsBought = 0;
int funds = 100;
for (int price = 10; funds >= price; price += 10) {
itemsBought++;
funds -= price;
}
System.out.println(itemsBought + " items bought.");
System.out.println("Money left over: "+ funds + " cents");
} Item 32: Avoid strings where other types are more appropriateStrings are poor substitutes for other value types. More generally, if there's an appropriate value type, whether
primitive or object reference, you should use it; if there isn't, you should write one.Strings are poor substitutes for aggregate types. A better approach is simply to write a class to represent the aggregate, often a private static member class
Strings are poor substitutes for capabilities. Occasionally, strings are used to grant access to some functionality, replace the string with an unforgeable key (sometimes called a capability).
Item 33: Beware the performance of string concatenationDon't use the string concatenation operator to combine more than a few strings unless performance is irrelevant. Use StringBuffer's append method instead. Alternatively, use a character array, or process the strings one at a time instead of combining them.
Item 34: Refer to objects by their interfaces
If appropriate interface types exist, parameters, return values, variables, and fields should all be declared using interface types.
// Good - uses interface as type
List subscribers = new Vector(); rather than this:
// Bad - uses class as type!
Vector subscribers = new Vector(); If you get into the habit of using interfaces as types, your program will be much more flexible. For example, the first
declaration could be changed to read
List subscribers = new ArrayList(); There is one caveat: If the original implementation offered some special functionality not required by the general contract of the interface and the code depended on that functionality, then it is critical that the new implementation provide the same functionality. For example, if the code surrounding the first declaration depended on the fact that Vector is synchronized,
then it would be incorrect to substitute ArrayList for Vector in the declaration.
It is entirely appropriate to refer to an object by a class rather than an interface if no appropriate interface exists.
For example, it is perfectly appropriate to use a value class as a parameter, variable, field, or return type.
If an object belongs to such a
class-based framework, it is preferable to refer to it by the relevant
base class, which is
typically abstract, rather than by its implementation class.
A final case in which there is no appropriate interface type is that of classes that implement an interface but provide extra methods not found in the interface—for example, LinkedList. Such a class should be used only to refer to its instances if the program relies on the extra methods: it should never be used as a parameter type (Item 25).
Item 35: Prefer interfaces to reflection
Reflection comes at a price:
You lose all the benefits of compile-time type checking.
The code required to perform reflective access is clumsy and verbose.
Performance suffers.
As a rule, objects should not be accessed reflectively in normal applications at run time.
You can obtain many of the benefits of reflection while incurring few of its costs by using it only in a very limited form. For many programs that must use a class unavailable at compile time, there exists at compile time an appropriate interface or superclass by which to refer to the class (Item 34). If this is the case, you can create instances reflectively and access them normally via their interface or superclass. If the appropriate constructor has no parameters, as is usually the case, then you don't even need to use the java.lang.reflect package; the Class.newInstance method provides the required functionality.
// Reflective instantiation with interface access
public static void main(String[] args) {
// Translate the class name into a class object
Class cl = null;
try {
cl = Class.forName(args[0]);
} catch(ClassNotFoundException e) {
System.err.println("Class not found.");
System.exit(1);
}
// Instantiate the class
Set s = null;
try {
s = (Set) cl.newInstance();
} catch(IllegalAccessException e) {
System.err.println("Class not accessible.");
System.exit(1);
} catch(InstantiationException e) {
System.err.println("Class not instantiable.");
System.exit(1);
}
// Exercise the set
s.addAll(Arrays.asList(args).subList(1, args.length-1));
System.out.println(s);
} Item 36: Use native methods judiciously
Think twice before using native methods. Rarely, if ever, use them for improved performance. If you must use native methods to access low-level resources or legacy libraries, use as little native code as possible and test it thoroughly. A single bug in the native code can corrupt your entire application.
Item 37: Optimize judiciously
Strive to write good programs rather than fast ones.
Strive to avoid design decisions that limit performance.
Consider the performance consequences of your API design decisions.
It is a very bad idea to warp an API to achieve good performance.
Measure performance before and after each attempted optimization.
Item 38: Adhere to generally accepted naming conventions
Internalize the standard naming conventions and learn to use them as second nature. The typographical conventions are straightforward and largely unambiguous; the grammatical conventions are more complex and looser. To quote from The Java Language Specification, "These conventions should not be followed slavishly if long-held conventional usage dictates otherwise." Use common sense.