- 
Tip 1 - Don't substitute another type for Object in the equals declaration
 - 
For a detailed discussion see Effective Java [Bloch01], pp. 35.
 
- 
Tip 2 - Object the general contract when overriding equals
 - 
For a detailed discussion see Effective Java [Bloch01], pp. 25.
 
- 
Tip 3 - Always override hashCode when you override equals
 - 
For a detailed discussion see Effective Java [Bloch01], pp. 36.
 
- 
Tip 4 - Always override equals when you override hashCode
 
- 
Tip 5 - Always override toString
 - 
For a detailed discussion see Effective Java [Bloch01], pp. 42.
 
- 
Tip 6 - Use interfaces only to define types
 - 
For a detailed discussion see Effective Java [Bloch01], pp. 89.
 
- 
Tip 7 - Replace structures with classes
 - 
For a detailed discussion see Effective Java [Bloch01], pp. 97.
 
- 
Tip 8 - Return zero-length arrays, not nulls
 - 
For a detailed discussion see Effective Java [Bloch01], pp. 134.
 
- 
Tip 9 - Adhere to generally accepted naming conventions
 - 
For a detailed discussion see Effective Java [Bloch01], pp. 165.
 
- 
Tip 10 - Refer to objects by their interfaces
 - 
For a detailed discussion see Effective Java [Bloch01], pp. 156.
 
- 
Tip 11 - Never declare that a method "throws Exception"
 - 
For a detailed discussion see Effective Java [Bloch01], pp. 181.
 
- 
Tip 12 - Never declare that a method "throws Throwable"
 - 
For a detailed discussion see Effective Java [Bloch01], pp. 181.
 
- 
Tip 13 - Don't ignore exceptions
 - 
For a detailed discussion see Effective Java [Bloch01], pp. 187.
 
- 
Tip 14 - Never invoke wait outside a loop
 - 
For a detailed discussion see Effective Java [Bloch01], pp. 201.
 
- 
Tip 15 - Avoid thread groups
 - 
For a detailed discussion see Effective Java [Bloch01], pp. 211.
 
- 
Tip 16 - Document collection types
 - 
As long as there are no strong-typed collections (a.k.a. Java Generics support) available,
it is best to document the object type of the items hold by a collection.
 - Example 4.154. Collection comment | 
private static final List _favorableTypes = new ArrayList(20); // List of <String>
 |  
 
- 
Tip 17 - Adhere to naming convention for collection types
 - 
If you use comments to document the object type of collection items, you should conform to
a generally accepted naming convention.
 
- 
Tip 18 - Avoid empty finally blocks
 - 
Empty finally blocks are of no use and may indicate programmer errors.
 - Example 4.155. Empty finally block | 
Writer writer = null;
try
{
    writer = new BufferedWriter(new FileWriter(file));
    write.write(data);
}
catch (IOException ex)
{
    System.err.println("file could not be written -- " + file);
}
finally
{
}
 |  
 
- 
The programmer certainly wanted to close the Writer in the
finally block to ensure that allocated system resources will be freed.
 
- 
Tip 19 - Avoid variable shadowing
 - 
Variable shadowing should be avoided on general principle, as it tends to be confusing.
 - 
For more information about shadowing, see the
Java Developer Connection (JDC) Tech Tips, October 10, 2000
(
http://developer.java.sun.com/developer/TechTips/2000/tt1010.html#tip2, subscription needed) or
section 6.3.2, "Obscured Declarations," section 7.5.2,
"Type-Import-on-Demand Declaration," section 8.4.6, "Inheritance, Overriding, and Hiding,"
section 8.4.8.5, "Example: Invocation of Hidden Class Methods," and section 14.4.3,
"Shadowing of Names by Local variables" in "The Java Language Specification Second
Edition" by Gosling, Joy, Steele, and Bracha
(http://java.sun.com/docs/books/jls/).
 
- 
Tip 20 - Add NOI18N comment for String literals
 - 
Enabling this tip will cause warnings for all String literals without associated
/* NOI18N */ comment.
 - 
Internationalizing Java applications is often done with nifty tools that use marker
comments to indicate that a given String literal should not be considered for localization.
Most tools (at least the ones I know of) use trailing single-line comments which may not
be very robust for processing with a formatting tool such as Jalopy. In contrast the author
uses a multi-line comment of the form /* NOI18N */ that gets directly
placed after a String literal and will therefore always stuck with it.
 - Example 4.156. $NON-NLS-1$ comment | 
FileDialog dialog = new FileDialog(this,
    ResourceBundle.getBundle(BUNDLE_NAME)
    .getString("BTN_SAVE_AS", FileDialog.SAVE); //$NON-NLS-1$
 |  
 
- 
This trailing comment could be easily moved away from its String literal during formatting
which would result in an unwanted notice on successive internationalization runs.
 - Example 4.157. $NON-NLS-1$ comment | 
FileDialog dialog =
    new FileDialog(this,
                   ResourceBundle.getBundle(BUNDLE_NAME).
                                  getString("BTN_SAVE_AS",
                   FileDialog.SAVE); //$NON-NLS-1$
 |  
 
- Example 4.158. NOI18N comment | 
FileDialog dialog =
    new FileDialog(this,
                   ResourceBundle.getBundle(BUNDLE_NAME).
                                  getString("BTN_SAVE_AS" /* NOI18N */),
                   FileDialog.SAVE);
 |