2.6Annotations

Use the same guidelines as for regular class for naming of custom annotations.

Do not start annotation properties with “get”.

Example:

public @interface Field {

boolean required() default false;

}

See Sun Java Annotations Guide for more examples.

2.7Exceptions

You should always add the suffix Exception to custom exception classes. The following is an example of a correctly named exception class:

ObjectNotFoundException

RuntimeException

2.8Enumerations

The following rules outline the naming guidelines for enumerations:

• Use Pascal case for enum types.

• For enum element names use the same conventions as for constants.

• Do not suffix enum element names with enum name.

• Do not start enumeration properties with “get”.

• Do not use an enum suffix on enum type names.

• Use a singular name for enum types.

Example:

public enum Fruit {

LEMON (“sour”),

PINEAPPLE (“sweet”);

private final String taste;

Fruit(String taste) {

this.taste = taste;

}

public String taste() {

return this.taste;

}

}

See Sun Java Enums Guide for more examples.

2.9Fields

The following rules outline the naming guidelines for class fields:

• Use nouns, noun phrases, or abbreviations of nouns to name fields.

• Use camel case.

• Use descriptive parameter names. Parameter names should be descriptive enough that the name of the parameter and its type can be used to determine its meaning in most scenarios. For example, visual design tools that provide context sensitive help display method parameters to the developer as they type. The parameter names should be descriptive enough in this scenario to allow the developer to supply the correct parameters.

• Use names that describe a parameter's meaning rather than names that describe a parameter's type. Development tools should provide meaningful information about a parameter's type. Therefore, a parameter's name can be put to better use by describing meaning. Use type-based parameter names sparingly and only where it is appropriate

• Avoid unnecessary abbreviations.

• Do not declare fields as public.

2.10Static Fields

The following rules outline the naming guidelines for static fields:

• Use nouns, noun phrases, or abbreviations of nouns to name static fields.

• Declare public static fields as “final”.

• Use upper case with words separated by underscores for class constants.

Example:

public class Foo {

private static final Log LOG = LogFactory.getLog(Foo.class);

public static final String BAR = “bar”;

private static final Foo INSTANCE = new Foo();

public static Foo getInstance() {

return INSTANCE;

}

}

2.11Parameters

The following rules outline the naming guidelines for parameters:

• Use camel case for parameter names.

• Use descriptive parameter names. Parameter names should be descriptive enough that the name of the parameter and its type can be used to determine its meaning in most scenarios. For example, visual design tools that provide context sensitive help or code auto completion display method parameters to the developer as they type. The parameter names should be descriptive enough in this scenario to allow the developer to supply the correct parameters.

• Use names that describe a parameter's meaning rather than names that describe a parameter's type. Development tools should provide meaningful information about a parameter's type. Therefore, a parameter's name can be put to better use by describing meaning. Use type-based parameter names sparingly and only where it is appropriate.

The following is an example of correctly named parameters:

public String process(char[] value, int offset, int count)