Naming Conventions

Many programming languages, programming language communities, and local CodingStandards adopt various naming conventions, wherein the name assigned to an object/variable/type/function/whatever is augmented in some way to convey additional information (besides the basic purpose). Some of these schemes are commonplace; some are controversial--and some are compiler enforced.

Advantages of NamingConventions:

Provide additional info that the programmer can see everywhere the variable is used. Especially useful if the information is something that the language implementation (compiler, interpreter) won't check.
Resolve potential naming conflicts, such as adding a module prefix to extern symbols in CeeLanguage (to avoid NamespacePollution)

Disadvantages of NamingConventions:

May provide information that the environment (compiler, editor, etc.) can determine for the programmer by other means.
May complicate ReFactoring. If the relevant information changes, then the name may have to change too; if it doesn't...
The name may become inconsistent with the attribute the name is supposed to encode.

Examples:

HungarianNotation. The encoding of the type of a variable/object in its name. This has its own page, enough said here.
Sigils in languages such as PerlLanguage and LispLanguage.
Module prefixes in C, as mentioned above.
Use of "m_" or similar prefixes (common in CeePlusPlus and Java) to identify member variables
Use of "g_" or similar to identify GlobalVariables
Use of English articles or pronouns (the, a, my) to identify temporaries, member variables, etc. Common in SmalltalkLanguage
UncleBobsNamingConventions
In languages which don't have implementation-enforced encapsulation (i.e. CommonLispObjectSystem, PythonLanguage), prefixes to identify what parts of a class are "private" and should be left alone by clients.
Use in SchemeLanguage of ! suffix on functions with SideEffects, ? suffix on predicates. Use of -p suffix in CommonLisp for predicates.
Use of get_, set_, is_ prefixes in many languages for accessors, mutators, and predicates. Practically mandatory for JavaBeans.

Anyone else seen these?

Use of just a "_" prefix to identify system level functions
Use of just a "__" prefix to identify "really" system level functions
Use of "p_" for pointers
Use of "LP" in win32 for pointers
Use of "tmp_" or "temp_" for temporary variables
Use of "foo_/bar_/cat_/dog_" for variables not meant to be used in production code (i.e. only for tests)
Use of "gl" for OpenGL functions
Use of "doStuff" i.e. lowercase word, followed by uppercase word for class methods

(SmellsLikeJava)

MixedCase for class names
mixedCase for most other names
UPPER_CASE for final constants
lower_case for private methods

That naming standard is common in the C/C++ world, and certainly predates Java (though it isn't adopted by the C/C++ standard, which use lower_case for just about everything...with a few exceptions I can think of)

I have one naming convention that I'd like to see:

Lowercase l, the digit 1, and uppercase I are not to be used in names except when the context within the name (ie: spelling) makes it clear which one it is. Ditto O and 0.

Just spent 1/2 an hour trying to connect to SystemServicesS1 when I should have been connecting to SystemServicesSl - the "Sl" is for "StateLess", but being new to the project, I did not know this.

Better fonts would reduce the frequency of these errors. If you have Lucida Sans Console it is decent for distinguishing everything but "zero" and "big Oh". -- RobertField