In order to make it easier for programmers working on the same codebase to easily read each other's (and their own!) code, we need to enforce certain standard coding conventions. These conventions will also be helpful when comparing code revisions under version control, as the code should be formatted consistently and no irrelevant formatting-related differences will appear in the diff.
First, Sun has their own code standards guidelines here: http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html. Like most coding guidelines, these are quite reasonable and differ only in minor details from other guidelines.
The web page http://geosoft.no/development/javastyle.html also has some very nice tips. Note that we won't 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, in order to perform object navigations that aren't already defined by Hibernate mappings.
Here are some additional notes:
Not surprisingly, a lot can be learned from good Smalltalk style. The books "Smalltalk With Style" (Klimas, Skublics, Thomas) and "Smalltalk Best Practices Patterns" (Kent Beck) provide a lot of good ideas for code organization and naming that are applicable to Java as well as Smalltalk.
All code should be:
Classes should use specific, not package-based imports, where practical. I.e. import com.foo.UsefulClass, not com.foo.*.
Variables should generally be private. Only create accessor (e.g. get/set) methods when absolutely needed ("Dont reveal your private parts").
Prefix "getter" methods with "get", e.g. "getFoo()", setters with "set", e.g. "setBar(aBar)". Don't use "Flag" or "Switch", or abbreviations thereof, i.e. "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.
Don't abbreviate except for standard industry abbreviations (i.e. 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, e.g.
List someList = new ArrayList();
...
Map someMap = new HashMap();
...
This lets you change your mind about implementation (e.g. ArrayList to LinkedList) without breaking any code.
3. Collection Naming Guidelines
5. Java/COBOL Naming Guidelines
Here are our project guidelines for naming properties:
The class name for a collection includes the owning entity name and the collection name in singular form.
<owning_entity><collection_name_in_singular_form>
Examples:
For collections, the one-off generation created a large number of collection names. Many of these are overly verbose, and should be shortened. Simply modify the collectionName in the entity annotation. Here are guidelines:
Here are guidelines for naming Lookups (on the Lookup Field maintenance):
Here are guidelines for naming Lookups Value properties (on Lookup Value maintenance):
When coding Java classes for Java -> Cobol processing, the following standards should be applied.
There are 'type' entities that control the characteristics for their 'instance' entities. These are tables typically named CI_CHTY_<type_entity>, e.g., CI_CHTY_CCTY. These type entities specify a list for its instances the valid characteristic types, default characteristic types, required characteristic types, etc. This list is the type entity's Characteristic Controls.
The following are the naming conventions for the characteristic controls:
Characteristic control class |
<type_entity>CharacteristicControl |
Characteristic control collection |
characteristicControls |
For example, the class name for characteristic control of Customer Contact Type is CustomerContactTypeCharacteristicControl.
And the collection is defined as follows:
/**
* @version $Revision: #1 $
* @BusinessEntity (tableName = CI_CC_TYPE,
oneToManyCollections = { @Child (collectionName = characteristicControls, childTableName = CI_CHTY_CCTY)})
*/