[Skip to content]
TRIEMAX Software
You are here: Home > Products > Jalopy >

### 2.6.14. Code Inspector

Lets you configure the Code Inspector. The Code Inspector inspects Java source files for naming convention violations and possible code weaknesses.

### 2.6.14.1. Checking

Lets you control the general Code Inspector settings.

Figure 2.96. Code Inspector settings page

#### 2.6.14.1.1. General

###### Enable

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

#### 2.6.14.1.2. Checks

Lets you selectively choose what actions should be performed during inspection.

###### Obey the general contract when overriding equals

Checks whether the body of a `equals` method contains a `throw` statement that would violate the equals contract. Only applies if the method body does contain more than one statement; thus, if the method body consists of a single `throw` statement, we assume you know what you do and leave it alone. For more information see Effective Java [Bloch01], Item 7, pp. 32.

Don't substitute another type for `Object` in the equals declaration

The `equals` method should not be overloaded.

Example 2.841. Overloaded equals - DO NOT USE!

    public boolean equals(MyClass o) {
        ....
    }

For a detailed discussion see Effective Java [Bloch01], Item 7, pp. 35.

###### Always override hashCode when you override equals

Failure to do so will result in a violation of the general contract for `Object#hashCode`, which will prevent the class from functioning properly in conjunction with all hash-based collections, including `HashMap` and `HashSet`.

For a detailed discussion see Effective Java [Bloch01], Item 8, pp. 36.

###### Always override toString

It might be quite useful for diagnostic purposes to have objects generating interesting information with `toString`. This way you can easily use logging techniques to track programs execution.

Example 2.842. Provide useful toString() implemenation

    System.out.println("Failed to connect: " + phoneNumber);

For a detailed discussion see Effective Java [Bloch01], Item 9, pp. 42.

###### Use interfaces only to define types

Interfaces should say something about what a client can do with instances of the class. It is inappropriate to define an interface for any other purpose.

When enabled, Jalopy warns about uses of the so-called constant interfaces pattern, i.e. an interface that only consists of constants.

Example 2.843. Constant interface pattern - DO NOT USE!

    public interface PysicalConstants {

        /** Boltzmann constant (J/K) */
        double BOLTZMANN_CONSTANT = 1.3806503e-23;

        /** Mass of the electron (kg) */
        double ELECTRON_MASS = 9.10938188e-31;
    }

For a detailed discussion see Effective Java [Bloch01], Item 89, pp. 89.

###### Replace structures with classes

Degenerated classes consisting soleley of data fields are loosely equivalent to C structures, but should not be used as they do not offer the benefits of encapsulation.

Example 2.844. Public degenerate class - DO NOT USE!

    public class Point {
        public float x;
        public float y;
    }

For a detailed discussion see Effective Java [Bloch01], Item 19, pp. 97.

###### Return zero-length arrays, not nulls

There is really no reason to ever return `null` from an array-valued method instead of returning a zero-length array.

For a detailed discussion see Effective Java [Bloch01], Item 27, pp. 134.

###### Adhere to custom naming conventions

Following a naming convention aids readibility and maintenance as confusion and irritation is avoided.

For a detailed discussion see Effective Java [Bloch01], Item 38, pp. 165.

###### Refer to objects by their interfaces

When possible, always use the interface type for parameters, return values, variables and fields as your program will be much more flexible.

When enabled, Jalopy will print warnings when the different Java collection implementations are used directly.

Example 2.845. // Good - uses interface as type

    List subscribers = new ArrayList();

Example 2.846. // Bad - uses interface as type - DO NOT USE!

    ArrayList subscribers = new ArrayList();

For a detailed discussion see Effective Java [Bloch01], Item 34, pp. 156.

###### Never declare that a method "throws Exception"

It is usually bad practise to declare that a method throws `Exception` because it obscures any other exception that may be thrown in the same context and denies any guidance to the programmer concering the exceptions that the method is capabable of throwing.

For a detailed discussion see Effective Java [Bloch01], Item 44, pp. 181.

###### Never declare that a method "throws Throwable"

It is usually bad practise to declare that a method throws `Throwable` because it obscures any other exception that may be thrown in the same context and denies any guidance to the programmer concering the exceptions that the method is capabable of throwing.

For a detailed discussion see Effective Java [Bloch01], Item 44, pp. 181.

###### Don't ignore exceptions

An empty catch block defeats the purpose of exceptions. At the very least, the catch block should contain a comment explaining why it is appropriate to ignore the exception.

Example 2.847. Empty catch block ignores exception - DO NOT USE!

    try {
        ...
    } catch (SomeException ex) {
    }

For a detailed discussion see Effective Java [Bloch01], Item 47, pp. 187.

###### Never invoke wait outside a loop

Always use the `wait` loop idiom to invoke the `wait` method. Never invoke it outside of a loop as the loop serves to test the condition before and after waiting ensuring liveness and savety

For a detailed discussion see Effective Java [Bloch01], Item 50, pp. 201.

###### Avoid thread groups

As thread groups are largely obsolete, don't use them. They don't provide much in the way of useful functionality, and much of the functionality they do provide is flawed.

For a detailed discussion see Effective Java [Bloch01], Item 53, pp. 211.

###### Avoid empty finally blocks

Empty `finally` blocks are of no use and may indicate programmer errors.

Example 2.848. Empty `finally` block

    Writer writer = new BufferedWriter(new FileWriter(file));

    try {
        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.

###### Add NOI18N comment for string literals

Enabling this check 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 2.849. $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 2.850. $NON-NLS-1$ comment (moved)

    FileDialog dialog =
        new FileDialog(this,
                       ResourceBundle.getBundle(BUNDLE_NAME).
                                      getString("BTN_SAVE_AS",
                       FileDialog.SAVE); //$NON-NLS-1$

Example 2.851. NOI18N comment

    FileDialog dialog =
        new FileDialog(this,
                       ResourceBundle.getBundle(BUNDLE_NAME).
                                      getString("BTN_SAVE_AS" /* NOI18N */),
                       FileDialog.SAVE);

###### Add informative comment for collection fields

When not using strong-typed collections (a.k.a. Java Generics), it is best to document the object type of the items hold by a collection. When enabled, Jalopy checks for the existence of such comments and warns when they are missing.

Example 2.852. Collection comment

    private List _favorableTypes = new ArrayList(20); // List of <String>

###### Warn about lines that exceed the maximal line length

When enabled, prints a warning for every line that was not printed in between the maximal line length.

Example 2.853. Line length limit

    throw new IllegalArgumentException(                           |
        "condition must be one of WHEN_IN_FOCUSED_WINDOW or WHEN_FOCUSED");
                                                                  |

###### Suppress within //J- //J+ pragma comments

When enabled, no warnings are printed for code sections enclosed with pragma comments.

Since 1.8

Example 2.854. Line length limit

    //J-
    throw new IllegalArgumentException(                           |
        "condition must be one of WHEN_IN_FOCUSED_WINDOW or WHEN_FOCUSED");
    //J+                                                          |

#### 2.6.14.2. Naming

Lets you specify the naming constraints for different Java source file elements. These constraints are naturally expressed with regular expressions.

Note that you have to enable both the Code Inspector and the naming convention check in order to see naming checks performed. See "Adhere to naming conventions" for more information.

Figure 2.97. Code Inspector Naming settings page

The list component displays all provided naming checks along with their current regular expression.

Selecting an item in the list and either pressing the Change... button or double-clicking the item will open a dialog that lets you change the regular expression.

##### 2.6.14.2.1. Change Naming Pattern

The Change Naming Pattern dialog lets you interactively craft a valid regular expression for a naming check.

Figure 2.98. Change Naming Pattern

###### Regex

The Regex text field is where you have to insert the regular expression. This text field initially contains the current pattern for the list item that is under construction.

The used regular expression syntax is that of Perl 5.003. See Mastering Regular Expressions [Friedl97] for an in-depth look at this regular expression flavor. The defined pattern must match exactly.

###### String

The String text field is where you have to enter a string that should be matched by the specified regular expression. This text field is initially empty.

###### Test

Once you have edited the two text fields you may want to use the Test button to perform a pattern matching test in order to make sure that the specified regex matches as desired.

You will be informed about the match status and can decide whether you want to alter your pattern and/or test string and restart the procedure.

Figure 2.99. Successful regex test

Figure 2.100. Failed regex test

###### Change

If you are finished editing the regular expression, you can press the Change button to take over.

###### Cancel

You can always use the Cancel button to cancel editing at any time. The dialog will be closed and no changes applied to the list.