2.12Methods

The following rules outline the naming guidelines for methods:

• Use verbs or verb phrases to name methods.

• Use camel case.

• Do not add information about parameter types in method name (use overloading instead).

• Avoid using of varargs (variable count of arguments) methods.

The following are examples of correctly named methods.

removeAll()

process(char[] source);

process(String source);

2.13Field Accessors (Java Bean properties)

The following rules outline the naming guidelines for Java Bean properties:

• Use field name with get prefix for reading field, but for boolean (not java.lang.Boolean) is prefix should be used.

• Use field name with set prefix for writing field for all types.

• Only exceptions are field names, which can conflict with Java reserved words (for instance class).

• Do not add business logic into accessors.

For example:

private String name;

private bool empty;

// Keyword conflict

private Class clazz; // “class” is not acceptable here

public String getName() {

return this.name;

}

public void setName(String name) {

this.name = name;

}

pbulic String getClass() {

return this.clazz;

}

public void setClass(String clazz) {

this.clazz = clazz;

}

public boolean isEmpty() {

return this.empty;

}

public void setEmpty(boolean empty) {

this.empty = empty;

}

2.14Generics

The following rules outline the naming guidelines for type parameters:

• Use Pascal case.

• Do name generic type parameters with descriptive names, unless a single letter name is completely self-explanatory and a descriptive name would not add value.

• Consider using T and E as the type parameter names for types with one single letter type parameter.

• Do prefix descriptive type parameter names with “T”.

• Consider indicating constraints placed on a type parameter in the name of parameter. For example, a parameter constrained to Session may be called TSession.

For example,

public interface SessionChannel<TSession> { … }

public delegate TOutput Converter<TInput, TOutput>(TInput from);

public class List<T> { … }

public class Map<T, E> { … }

See Sun Java Generics Guide for more examples.

2.15Summary

Indentifier	Case	Example
Class	Pascal	Application
Enum	Pascal	ErrorLevel
Enum Value	Upper with underscores	FATAL
Exception Class	Pascal	DataAccessException (always ends with Exception)
Annotation	Pascal	Field
Interface	Pascal	Closeable
Method	Camel	toString
Package	Lower	org.example
Parameter	Camel	parameterName
Accessor	Camel	[get|set]Field (usually similar to field name)
Field	Camel	classField
Constant	Upper with underscores	STATIC_FIELD
Local Variable	Camel	localVariable
Type parameter	Pascal	T, E or T<Descriptive Name>

3.Comments

3.1Introduction

All source code documenting inside source files has to follow Java language specification (“Documentation Comments” appendix). Specific additions are described in the following sub-sections.

3.2Class comments

It’s recommended to provide enough details on each source code part (method, class, etc) in accordance with Java language specification. At least class general description and @author section is absolutely mandatory. No file should be delivered without this part of source code documentation.

3.3Method comments

All public and protected methods should have detailed documentation. Description section is absolutely mandatory. If method throws non-runtime exceptions they should be documented (for example, NullPointerException in case of passing null parameter may not be documented). Parameters and return value should be documented if method is complex or its name is not enough understandable.

In case of get/set pair, it is enough to document only getter method.