see http://java.sun.com/docs/codeconv/html/CodeConventions.doc8.html The prefix of a unique package name is always written in all-lowercase ASCII letters and should be one of the top-level domain names, currently com, edu, gov, mil, net, org, or one of the English two-letter codes identifying countries as specified in ISO Standard 3166, 1981. Subsequent components of the package name vary according to an organization's own internal naming conventions. Such conventions might specify that certain directory name components be division, department, project, machine, or login names. Class names should be nouns, in mixed case with the first letter of each internal word capitalized. Try to keep your class names simple and descriptive. Use whole words-avoid acronyms and abbreviations (unless the abbreviation is much more widely used than the long form, such as URL or HTML). Interface names should be capitalized like class names. Methods should be verbs, in mixed case with the first letter lowercase, with the first letter of each internal word capitalized. Except for variables, all instance, class, and class constants are in mixed case with a lowercase first letter. Internal words start with capital letters. Variable names should not start with underscore _ or dollar sign $ characters, even though both are allowed. Variable names should be short yet meaningful. The choice of a variable name should be mnemonic- that is, designed to indicate to the casual observer the intent of its use. One-character variable names should be avoided except for temporary "throwaway" variables. Common names for temporary variables are i, j, k, m, and n for integers; c, d, and e for characters. The names of variables declared class constants and of ANSI constants should be all uppercase with words separated by underscores ("_"). (ANSI constants should be avoided, for ease of debugging.) Searches for code that represents bad practice The finalize method should not be overridden Normally there is no need to call updateUI, did you mean repaint()? Calls from inside the method updateUI are ok! Mutable static fields could be changed by malicious code or by accident from another package There is no need to mark a method in a final class as final. This is implied by the context Because it's impossible to inherit from a class that has only private constructors the class should be declared final. To minimize false positives the cql checks if all methods are static Classes that only have private constructors and only consist of static classes should be named *Util, *Helper or *Factory Do not use interfaces for holding constants. Prefer using final classes It's absolutely unnecessary to declare methods from java.lang.Object in an interface Each (endpoint) class should override Object#toString(), Object#equals(Object) and Object#hashCode() Do not instantiate Booleans, use the constants Boolean.TRUE and Boolean.FALSE or use the static factory method Boolean#valueOf(boolean) (boolean)') } }; ]]> There's not much sense for extending a superclass if the extending class contains static methods only Classes extending classes outside of their own package (or better: classes not written by yourself) is dangerous and can lead to fragile software. Consider usage of composition instead of inheritance [Effective Java Item 26] Classes offering reset methods often indicates poor design quality and usually lead to problems in a multi-threaded context. A method's returntype should be the interface instead of the concrete implementation. Since SwingUtilities2 is not a public API you should never refer SwingUtilities2 (or any other sun/com.sun classes) An Error is a subclass of Throwable that indicates serious problems that a reasonable application should not try to catch. If you'd like to throw an unchecked exception you should throw an exception extending RuntimeException Equals is not implemented properly in those classes, new StringBuilder("foo").equals(new StringBuilder("foo")) will return false If a method contains classes in its signature with a lower visibility than the method itself it cannot be used in the context it is intended If a method contains classes in its signature with a lower visibility than the method itself it cannot be used in the context it is intended A method should not have more than 5 parameters (PC=Parameter Count) ','5') }; ]]> A method should not have more than 10 public methods nor more than 15 fields (PMC=Public Method Count, FC=Field Count). Because enums easily can have more than 15 fields they are excluded ', '10') | { metric('FC', '>', '15') && !modifier('ENUM') } }; ]]> A class should not have more than 4 parents (PARC=PARent Count) ','4') }; ]]> A method should not be overridden more than 3 times (MOC=Method Overriding Count) ','3') }; ]]> A class should not have more than 5 constructors (CC=Constructor Count) ','5') }; ]]> Method that are private and unused within the declaring class can be removed. Although the unused filter tries to detect calls done via reflection you should be sure the code is really not accessed by reflection before removing it. Fields that are private and unused within the declaring class can be removed. Although the unused filter tries to detect calls done via reflection you should be sure the code is really not accessed by reflection before removing it.