4.4. Code Inspector

Provides the configuration facility for the Jalopy Code Inspector. The Code Inspector is able to inspect Java source files for naming convention violations and possible code weaknesses.

4.4.1. General

Lets you control the general Code Inspector settings.

4.4.1.1. General

Enable

Lets you enable or disable the Code Inspector as a whole.

4.4.1.2. Tips

Lets you selectively choose what actions should be performed during inspection. Moving the mouse pointer onto a checkbox displays a minimalistic tooltip after a short delay.

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