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