General Naming Conventions

Names representing types or modules must be nouns and they must be written in mixed case starting with upper case:

	Line, FilePrefix

Variable names must be in mixed case starting with lower case:

	line, filePrefix

Makes variables easy to distinguish from types and effectively resolves potential naming collision as in the declaration Line line.

Names representing constants (or enum values) should be all uppercase using underscore to separate words:

	MAX_ITERATIONS, RED, MONDAY

Names representing methods must be verbs and they must be written in mixed case starting with lower case:

	find(), computeTotalWidth()

This is identical to variable names but, in Studio, methods are already distinguishable from variables by their specific form.

Abbreviations and acronyms should not be uppercase when used as a name:

	exportHtmlSource();    // NOT: exportHTMLSource();
	openDvdPlayer();       // NOT: openDVDPlayer();

Using all uppercase for the base name will trigger conflicts with the naming conventions given above. A variable of this type should be named dVD, hTML, and so on, which is obviously not very readable. Another problem is illustrated in the examples above. When the name is connected to another, the readability is seriously reduced. The word following the acronym does not stand out as it should.

Variables should not have prefixes or suffixes.

Given the fact that the PBL Editor has already colored variables in a different way depending on their scope (local, instance, and so on), it is not necessary to add prefixes:

	length as Int
	this.length = length

Generic variables should have the same name as their type:

	 assignTopic (topic : Topic)
	
	NOT assignTopic (value : Topic)
	NOT assignTopic (aTopic : Topic)
	NOT assignTopic (x : Topic)

Reduces complexity by reducing the number of terms and names that are used. Also, this makes it easier to deduce the type given a variable name only.

If, for some reason this convention does not seem to fit, it is a strong indication that the type name is badly chosen.

Non-generic variables have a role. These variables can often be named by combining role and type:

	startingPoint as Point
	centerPoint as Point
	loginName as Name

All names should be written in English.

	fileName NOT  nomArchivo

English is the preferred language for international development.

Variables with a large scope should have long names, and variables with a small scope can have short names.

Scratch variables used for temporary storage or indexes are best kept short. A programmer reading such variables should be able to assume that its value is not used outside a few lines of code. Common scratch variables are:

integers	i, j, k, m, n, i1, i2
booleans	b,b1,b2
reals	x,y,z,w
Strings	s,str

The name of the object is implicit and should be avoided in a method name.

	line.length
	
	NOT line.lineLength

The latter seems natural in the class declaration but it proves superfluous in use, as shown in the example.