Guidelines

First, there are basic code standards documented for Java here: Java Code Conventions. Like most coding guidelines, these are quite reasonable and differ only in minor details from other guidelines.

The web page Java Programming Style Guidelines also has nice tips. Note that we do not prefix instance variable names with underscores; instead, we use Eclipse syntax coloring to make ivars easily visible.

We use the prefix fetch in method names in entity implementation classes to perform object navigations that are not already defined by Hibernate mappings.

Here are some additional notes:

All code should be:

  • Written with tabs equal to 4 spaces, not hard tabs. Each level of indentation should be one tab.
  • Generally free of hard-coded magic strings or magic numbers (for example, max number of items in some list). If you need such a string or number value, you should use (or create) a constant or property.
  • Classes should use specific, not package-based imports, where practical. That is, import com.foo.UsefulClass, not com.foo.*.
  • Variables should generally be private. Only create accessor methods (for example, get/set) when absolutely necessary.
  • Prefix getter methods with get, for example, getFoo(); setters with set, for example, setBar(aBar). Do not use "Flag" or "Switch", or abbreviations thereof. For example, getAllowedSw() should be getIsAllowed(), and setAllowedSw(aBoolean) should be setIsAllowed(aBool).
  • Use camel-case instance and parameter variable names, without underscore prefixes or suffixes (do use uppercase for constants, as suggested in the guidelines reference above). Instance variables start with lower-case letters.
  • Methods should generally be public or private (again, to allow future subclassing). Use of interfaces is encouraged to declare useful sets of public methods.
  • Do not abbreviate, except for standard industry abbreviations (for example, HTML, HTTP). Use long, meaningful class, method, and variable names.
  • Methods should be short and clear. Instead of placing comments before a section of code in a method, rather create another method that describes what is being done by the method name.
  • When using Java API collections, reference them through generic interfaces, not specific implementation classes, for example:


   List someList = new ArrayList();
   ...
   Map someMap = new HashMap();
   ...

This lets you change your mind about implementation (for example, ArrayList to LinkedList) without breaking any code.