NamingConventions

Last edit January 22, 2011
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

See also: IdentifierPrefix