AnnotationsUse 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. Exceptions You should always add the suffix Exception to custom exception classes. The following is an example of a correctly named exception class: ObjectNotFoundException RuntimeException Enumerations The following rules outline the naming guidelines for enumerations: Ø Use Pascal case for enum types. Ø F or 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. Fields 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.
|
