+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);
+ |