Overview

The table below gives you a good overview which antipatterns are recognized by which PatternTesting subproject. The antipatterns are grouped by the subproject which can detect it. For a detailed description of the antipatterns see the section "Description" after the table.

Description

The antipatterns are alphabetically sorted. At the end of each description you find the subproject or class which can detect the antipattern.

Broken Initialization

If the instantiation of a class fails this kind of error is hard to find. The VM will report something like "ClassNotFoundException" .....

detected by: @GuardInitialization.
If the initialization will fail you'll see in the log which class could not be initialized.

example: patterntesting.sample.Crash, which is called by patterntesting.sample.CrashTest.

Faulty Default Generation

Look at the following code generated by eclipse:

public int compareTo(Fraction o) {
    // Auto-generated method stub
    return 0;
}

You can use it but you get always "0" as result. And perhaps you don't notice it but rely on the result. The same thing can happen with methods which are still under construction and not yet finished.

detected by: not really detected by PatternTesting, but you can put @NotYetImplemented or @UnsupportedOperation in front of the method to mark it as "implementation not finished" or "will not be supported".

example: patterntesting.sample.Fraction

Null Flag

Null values are used as flags for exceptional conditions (e.g. empty search result). If other methods try to access these values they can get a NullPointerException (see also The Null Flag bug pattern from Eric Allen).

To prevent this antipattern you should forbid null values as allowed value. The NullPointerTrap will help you to do this task. It disallows null values as arguments and as return value.

example: patterntesting.sample.Config (this is an example how you can use e.g. the @MayReturnNull annotation to indication that this method can return a null value)

Java Flow

This pattern is also known as "dead code". There are areas in your code which are "hot". That are these areas which are still under construction. But there are also areas which are "cold", which are ossified: nobody has the courage to change these places of code - they are dead. And the main development stream flows around these places of "cold code".

These cold places begin to slow down the whole development. You probably want to kick them out but you can't because you don't know if they are really needed.

detected by: patterntesting.runtime.monitor.ClasspathMonitor (dead classes) or patterntesting.runtime.monitor.ProfileStatistic (dead methods, together with @ProfileMe).

example: patterntesting.sample.World

Run-on initialization

Objects are not properly initialized and left attributes uninitialized. For a detailed description see Diagnosing Java Code: The Run-on Initializer bug pattern from Eric Allen.

System.out-Logging

Sometimes you find System.out.print or System.err.print statements in the code used for logging. Don't do that - use logging frameworks like Log4j or commons-logging. They provide not only filtering and formatting the output but you can send the log output not only to a file but also e.g. to the syslog facility of a Unix machine. So the adminstrator can decide where the output should be sent.

If you really need System.out or System.err put a @SuppressSystemOutWarning in front of the method or class.

detected by: patterntesting.check.ct.SopAspect

example: patterntesting.sample.World

Underscores

Underscores in Java names should only be used by constants, e.g. by static final attributes. Why? Because it is common sense and described by Sun's Java Code Conventions. If you see an underscore in a attribute name you know it is a constant or it is generated code.

detected by: patterntesting.check.ct.NamingConventions

Missing Antipattern

Are there some patterns missing? Or one of the pattern is known under a different name? Let us know. Neither via email to mailing list or as bug report.