Naming convention on generics

A note on naming conventions. We recommend that you use pithy (single character if possible) yet evocative names for formal type parameters. It’s best to avoid lowercase characters in those names, making it easy to distinguish formal type parameters from ordinary classes and interfaces. Many container types use E, for element, as in the examples above.

Avoid basic style errors

Many beginners to Java repeat the same basic style errors. Such style errors don't make your program incorrect, but they make your program less maintainable. In essence, many beginners write code that suffers from the same basic underlying defect of not being written with compassion for the reader.
There are in fact two target platforms for all code: the runtime hardware, and the human cerebral cortex. All code 'runs' in the human brain, in the sense that all code needs to be understood by a human being. Coding style is always concerned with this second target platform, not with the first.
Some common basic style errors :

• classes too long
• methods too long
• little or no javadoc
• no convention for distinguishing between local variables, arguments, and fields
• many empty catch blocks that suppress exceptions
• using exceptions to define regular program flow
• excessive use of the instanceof operator
• using floating point data to represent money
• preferring arrays over collections (especially in JDK 5+)

Some basic style errors are much more damaging to your code than others. The single most harmful bad habit is that of excessive length. Classes that are too long are hard to understand. As a guideline, if a class is more than about 300 lines long, you should likely consider splitting it up into smaller pieces. Similarly, methods that are more than a single screen are very likely too long, and would almost always benefit from being split into several methods.

Improving coding style into classes

Class and Interface declarations should be organized in the following manner: 
1. Class/Interface documentation. 
2. class or interface statement. 
3. Class (static) variables in the order public, protected, package (no access modifier), private. 
4. Instance variables in the order public, protected, package (no access modifier), private.
5. Constructors. 
6. Methods (no specific order). Reduce complexity by making the location of each class element predictable. 


Imported classes should always be listed explicitly.
import java.util.List; // NOT: import java.util.*; 
import java.util.ArrayList; 
import java.util.HashSet; 
Importing classes explicitly gives an excellent documentation value for the class at hand and makes the class easier to comprehend and maintain. Appropriate tools should be used in order to always keep the import list minimal and up to date.

Java specific naming convention

JFC (Java Swing) variables should be suffixed by the element type.
widthScale, nameTextField, leftScrollbar, mainPanel, fileToggle, minLabel, printerDialog
Enhances readability since the name gives the user an immediate clue of the type of the variable and thereby the available resources of the object.

Array specifiers must be attached to the type not the variable.
int[] a = new int[20]; // NOT: int a[] = new int[20]
The arrayness is a feature of the base type, not the variable. It is not known why Sun allows both forms.

Java source files should have the extension .java. Point.java Enforced by the Java tools.


The import statements must follow the package statement. import statements should be sorted with the most fundamental packages first, and grouped with associated packages together and one blank line between groups. 

 import java.io.IOException; 

import java.net.URL;

import java.rmi.RmiServer; 

import java.rmi.server.Server; 

import javax.swing.JPanel; 

import javax.swing.event.ActionEvent; 

import org.linux.apache.server.SoapServer; 

The import statement location is enforced by the Java language. The sorting makes it simple to browse the list when there are many imports, and it makes it easy to determine the dependiencies of the present package The grouping reduce complexity by collapsing related information into a common unit.


The package statement must be the first statement of the file.
All files should belong to a specific package. The package statement location is enforced by the Java language. Letting all files belong to an actual (rather than the Java default) package enforces Java language object oriented programming techniques. 

Specific cases of naming enhancing naming style

The term find can be used in methods where something is looked up.

vertex.findNearestVertex(); matrix.findSmallestElement(); node.findShortestPath(Node destinationNode);

Give the reader the immediate clue that this is a simple look up method with a minimum of computations involved. Consistent use of the term enhances readability.

The term initialize can be used where an object or a concept is established.

printer.initializeFontSet();

The American initializeshould be preferred over the English initialise. Abbreviation init must be avoided.




Plural form should be used on names representing a collection of objects.
Collection points; int[] values;
Enhances readability since the name gives the user an immediate clue of the type of the variable and the operations that can be performed on its elements.
 
n prefix should be used for variables representing a number of objects.
nPoints, nLines
The notation is taken from mathematics where it is an established convention for indicating a number of objects.

Note that Sun use num prefix in the core Java packages for such variables. This is probably meant as an abbreviation of number of, but as it looks more like number it makes the variable name strange and misleading. If "number of" is the preferred phrase, numberOf prefix can be used instead of just n. num prefix must not be used.

No suffix should be used for variables representing an entity number.
tableNo, employeeNo
The notation is taken from mathematics where it is an established convention for indicating an entity number.

An elegant alternative is to prefix such variables with an i: iTable, iEmployee. This effectively makes them named iterators.

Improving coding style into functions or methods

Method modifiers should be given in the following order: static abstract synchronized final native
The modifier (if present) must be the first modifier.
public static double square(double a); // NOT: static public double square(double a);
is one of public, protected or private while includes volatile and transient. The most important lesson here is to keep the access modifier as the first modifier. Of the possible modifiers, this is by far the most important, and it must stand out in the method declaration. For the other modifiers, the order is less important, but it make sense to have a fixed convention.