Specific Naming Conventions

Describes naming conventions

The term "compute" can be used in methods in which something is computed.

	computeAverage valueSet
	computeInverse matrix

Gives the reader the immediate clue that this is a potential time-consuming operation and, if used repeatedly, he/she might consider caching the result. Consistent use of the term enhances readability.

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

	findNearest Vertex   
	findMinElementIn matrix 
	NOT getMinElementIn matrix

Gives the reader the immediate clue that this is a simple look up method with a minimum of computations involved, but more expensive than a simple getter. Consistent use of the term enhances readability.

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

	initializeFontSetFor Printer

The American spelling of "initialize" should be used instead of the English "initialise". Abbreviation of "init" must be avoided.

"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 to indicate a number of objects.

If "number of" is the preferred statement, numberOf prefix can be used instead of just n. The num prefix must not be used.

The "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 the number of an entity.

Complementary names should be used for complementary concepts or actions:

add/remove
create/destroy
start/stop
insert/delete
increment/decrement
old/new
begin/end
first/last
up/down
min/max
next/previous
old/new
open/close
show/hide
get/set

Reduce complexity by symmetry, and avoid abbreviations in names wherever possible. For example, use computeSalary, rather than compSal.

Exception classes should be suffixed with Exception:

	AccessException

Exception classes are really not part of the main design of the code. Naming them like this makes them stand out relative to the other classes.

Functions (methods returning an object) should be named after what they return, and procedures (void methods), after what they do.

Increase readability. Makes it clear what the unit should do and, especially, what it is not supposed to do. Again, this makes it easier to keep the code free from causing undesired side effects.

Negation

Negated boolean variable names must be avoided. For example, isError is better than isNotError.

The reason is that a readability problem arises when the logical not operator is used, and double negative arises. It is not immediately clear what not isNotError means.

Abbreviations

When considering the use of an abbreviation, think of which kind of word you are using. Common words listed in a language dictionary should almost never be abbreviated. Avoid writing pt instead of point, comp instead of compute, init instead of initialize, and so forth.

On the other hand, there are also domain-specific phrases that are more naturally known through their acronym or abbreviation. These phrases should be kept abbreviated. For example, don't write: Hypertext Markup Language instead of HTML, or Central Processing Unit instead of CPU.