Generic class names to avoid

Overview

Java (Oracle Java update 2) has many classes with the same generic name. To avoid further confusion, I suggest avoiding these names if you can.

Most repeated

The following class names are repeated, 19 Handler, 16 Messages, 13 Util, 10 Element, 8 Attribute, 7 SecuritySupport, 7 Node, 6 Provider, 6 Header, 6 FactoryFinder, 6 Document. 5 SOAPBinding, 5 Repository, 5 Ref, 5 ORB, 5 Name, 5 Constants, 5 Connection, 5 Comment, 5 Binding, 5 Attributes,
This excludes the Apache XML library which repeats many names. If you include these libraries there are 26 classes called SecuritySupport.

Four times

Window, Version, Utility, Timer, Text, State, Signature, ServiceName, ServiceConfigurationError, Service, ResourceLoader, Queue, Policy, Parser, Operation, NativeLibLoader, Message, Label, JSObject, GetPropertyAction, FactoryFinder$ConfigurationError, Event, ConstantPool, AppletAudioClip, Action,

Three times

XMLWriter, Wrapper, WildcardTypeImpl, Visitor, Validator, Types, TypeMismatch, TypeInfo, Type, Trace, Token, Timestamp, Target, Symbol, StyleSheet, SOAPFault, SOAPConstants, Scope, Schema, ResourceManager, Resource, Resolver, Request, Reference, Properties, ProgressMonitor, PrincipalImpl, Principal, Port, PooledConnection, Pool, Pipe, Patcher, ParseException, OutputStream, ObjectStreamField, Navigator, NamespaceSupport$Context, NamespaceSupport, MimeType, MemoryCache, MarshalException, Manifest, Main, Location, List, JarVerifier, IOR, Invoker, InvalidName, Introspector, InputStream, Import, ImageCache, HTMLDocument, HTMLCollection, Headers, FinalArrayList, Filter, FileSystem, FactoryImpl, Extension, EventListener, ErrorHandler, Entity, EncryptedPrivateKeyInfo, Delegate, DataSource, CurrentOperations, CurrentHelper, Current, Counter, Context, ContentType, Config, Code, CharacterData, Certificate, CacheTable, Cache, Bridge, Base64, Authenticator, AttributeList, ArrayType, Array, AppletAudioClip$1, Annotation,

Appearing twice

Too many to mention.

Java Versions and Code Names

VERSION
CODE NAME RELEASE DATE


JDK 1.1.4
Sparkler Sept 12, 1997


JDK 1.1.5
Pumpkin Dec 3, 1997


JDK 1.1.6
Abigail April 24, 1998


JDK 1.1.7
Brutus Sept 28, 1998


JDK 1.1.8
Chelsea April 8, 1999


J2SE 1.2
Playground Dec 4, 1998


J2SE 1.2.1
(none) March 30, 1999


J2SE 1.2.2
Cricket July 8, 1999


J2SE 1.3
Kestrel May 8, 2000


J2SE 1.3.1
Ladybird May 17, 2001


J2SE 1.4.0
Merlin Feb 13, 2002


J2SE 1.4.1
Hopper Sept 16, 2002


J2SE 1.4.2
Mantis June 26, 2003


J2SE 5.0 (1.5.0)
Tiger Sept 29, 2004

Naming Convention–Differentiating field, argument,local variables and constant

Fields, arguments, local variables and constants are variables. It is common to use a variable naming convention to distinguish between fields, arguments, and local variables.

Within the body of a method, all of these types of variables can appear. Many find naming conventions to be a helpful aid in getting a rapid understanding of a method's implementation. These conventions have only one purpose : to pour understanding into the brain of the reader as quickly as possible.

To understand a method, you need to understand its data. An important part of understanding data is understanding where it is defined - as a field, argument, or local variable. Naming conventions which distinguish these cases usually allow the reader to understand an implementation more quickly, since they no longer need to scan the class to determine where items are defined.

Some different styles are :

• field : _foo, foo_, fFoo, this.foo, m_foo, myFoo
• argument : aFoo, pFoo
• local variable : foo
• constant : FOO_FOO

As well, some use a naming convention for type names, to distinguish between interfaces and regular classes :

• interface : IFooBar
• class : FooBar, CFooBar

Note that this 'I' and 'C' convention is fundamentally different from the other conventions mentioned above. This convention is visible to the caller, while the other naming conventions, being confined to the implementation, are not. Also note that class name is generally given on what it represents, and methods into it are named on the behaviour or function they do. Similarly interface name is given on what they add to class.

The example code on this site usually follows these conventions :

• field : fBlahBlah
• argument : aFooBar
• local variable : fooBar
• constant : FOO_BAR
• class : FooBar
• interface : IFooBar

The return value of a method is sometimes given a conventional name as well.

See also Sun's remarks on naming conventions in general.

See Also :

Conventional name for return value
Coding conventions
Avoid basic style errors

Naming Convention : Name for return value in method

Some people find it nice to name "return value" of the method as "result". So for eg. :

public String myMethod()
{
    ...// do something
    String result = ...
    ...//do something
    return result;
}

So in this way, when someone reads the method, he is clear what "result" is, and how it is being processed.

Naming Conventions for Exceptions in java

It's good practice to append the word "Exception" to the end of all classes that inherit (directly or indirectly) from the Exception class. Similarly, classes that inherit from the Error class should end with the string "Error".

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.

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.