Naming conventions (programming)
This article is licensed under the GNU Free Documentation License. It uses material from the Wikipedia article "Naming_conventions_(programming)".

In computer programming, a naming convention is a set of rules for choosing the character sequence to be used for identifiers in source code and documentation.

Reasons for using a naming convention (as opposed to allowing programmers to choose any character sequence) include the following:

• to reduce the effort needed to read and understand source code^[1];
• to enhance source code appearance (for example, by disallowing overly long names or abbreviations).

The choice of naming conventions can be an enormously controversial issue, with partisans of each holding theirs to be the best and others to be inferior. Colloquially, this is said to be a matter of "religion".^[2]

Potential benefits

Some of the potential benefits that can be obtained by adopting a naming convention include the following:

• to provide additional information (ie, metadata) about the use to which an identifier is put;
• to help formalize expectations and promote consistency within a development team;
• to enable the use of automated refactoring or search and replace tools with minimal potential for error;
• to enhance clarity in cases of potential ambiguity;
• to enhance the aesthetic and professional appearance of work product (for example, by disallowing overly long names, comical or "cute" names, or abbreviations);
• to help avoid "naming collisions" that might occur when the work product of different organizations is combined (see also: namespaces); and
• to provide meaningful data to be used in project handovers which require submission of program source code and all relevant documentation

Challenges

The choice of naming conventions (and the extent to which they are enforced) is often a contentious issue, with partisans holding their viewpoint to be the best and others to be inferior.

Moreover, even with known and well-defined naming conventions in place, some organizations may fail to consistently adhere to them, causing inconsistency and confusion.

These challenges may be exacerbated if the naming convention rules are internally inconsistent, arbitrary, difficult to remember, or otherwise perceived as more burdensome than beneficial.

Business value of naming conventions

Although largely hidden from the view of most business users, well-chosen identifiers make it significantly easier for subsequent generations of analysts and developers to understand what the system is doing and how to fix or extend the source code for new business needs.

For example, although the following:

a = b * c  

is syntactically correct, it is entirely opaque as to intent or meaning. Contrast this with:

weekly_pay = hours_worked * pay_rate

which implies the intent and meaning of the source code, at least to those familiar with the underlying context of the application.

Common elements

The exact rules of a naming convention depend on the context in which they are employed. Nevertheless, there are several common elements that influence most if not all naming conventions in common use today.

Length of identifiers

A fundamental element of all naming conventions are the rules related to identifier length (i.e., the finite number of individual characters allowed in an identifier). Some rules dictate a fixed numerical bound, while others specify less precise heuristics or guidelines.

Identifier length rules are routinely contested in practice, and subject to much debate academically.

Some considerations:

• shorter identifiers may be preferred as more expedient, because they are easier to type
• extremely short identifiers (such as 'i' or 'j') are very difficult to uniquely distinguish using automated search and replace tools
• longer identifiers may be preferred because short identifiers cannot encode enough information or appear too cryptic
• longer identifiers may be disfavored because of visual clutter

It is an open research issue whether programmers prefer shorter identifiers because they are easier to type, or think up, than longer identifiers, or because in many situations a longer identifier simply clutters the visible code and provides no perceived additional benefit.

Brevity in programming could be in part attributed to early linkers which required variable names to be restricted to 6 characters in order to save memory.

Letter case and numerals

Some naming conventions limit whether letters may appear in uppercase or lowercase. Other conventions do not restrict letter case, but attach a well-defined interpretation based on letter case. Some naming conventions specify whether alphabetic, numeric, or alphanumeric characters may be used, and if so, in what sequence.

Multiple-word identifiers

A common recommendation is "Use meaningful identifiers." A single word may not be as meaningful, or specific, as multiple words. Consequently, some naming conventions specify rules for the treatment of "compound" identifiers containing more than one word.

Word boundaries

As most programming languages do not allow whitespace in identifiers, a method of delimiting each word is needed (to make it easier for subsequent readers to interpret which characters belong to which word).

Delimiter-separated words

One approach is to delimit separate words with a nonalphanumeric character. The two characters commonly used for this purpose are the hyphen ('-') and the underscore ('_'), (e.g., the two-word name two words would be represented as two-words or two_words). The hyphen is used by nearly all programmers writing Cobol and Lisp; it is also common for selector names in Cascading Style Sheets. Many other languages (e.g., languages in the C and Pascal families) reserve the hyphen for use as the subtraction infix operator, and so it is not available for use in identifiers.

Letter-case separated words

Another approach is to indicate word boundaries using capitalization, thus rendering two words as either twoWords or TwoWords. The term CamelCase (or camelCase) is sometimes used to describe this technique. CamelCase, however, can spoil readability when acronym and initialism must be used as words. Moreover it may cause difficulty when the source code is inspected with a common spell checker such as "aspell" etc.

Metadata and hybrid conventions

Some naming conventions represent rules or requirements that go beyond the requirements of a specific project or problem domain, and instead reflect a greater over-arching set of principles defined by the software architecture, underlying programming language or other kind of cross-project methodology.

Hungarian notation

• Perhaps the most well-known is Hungarian notation, which encodes either the purpose ("Apps Hungarian") or the type ("Systems Hungarian") of a variable in its name^[3].

Positional Notation

A style used for very short (8 characters and less) could be: LCCIIL01, where LC would be the application (Letters of Credit), C for COBOL, IIL for the particular process subset, and the 01 a sequence number.

This sort of convention is still in active use in mainframes dependent upon JCL and is also seen in the 8.3 (maximum 8 characters with period separator followed by 3 character file type) MS-DOS style.

Composite word scheme (OF Language)

One of the earliest published convention systems was IBM's "OF Language" documented in a 1980s IMS (Information Management System) manual^{citation needed}.

It detailed the PRIME-MODIFIER-CLASS word scheme, which consisted of names like "CUST-ACT-NO" to indicate "customer account number".

PRIME words were meant to indicate major "entities" of interest to a system.

MODIFIER words were used for additional refinement, qualification and readability.

CLASS words ideally would be a very short list of data types relevant to a particular application. Common CLASS words might be: NO (number), ID (identifier), TXT (text), AMT (amount), QTY (quantity), FL (flag), CD (code), W (work) and so forth. In practice, the available CLASS words would be a list of less than two dozen terms.

CLASS words, typically positioned on the right (suffix), served much the same purpose as Hungarian notation prefixes.

The purpose of CLASS words, in addition to consistency, was to specify to the programmer the data type of a particular data field. Prior to the acceptance of BOOLEAN (two values only) fields, FL (flag) would indicate a field with only two possible values.

Language-specific conventions

C and C++ languages

• In C and C++, keywords and standard library identifiers are mostly lowercase. Identifiers representing macros are, by convention, written using only upper case letters (this is related to the convention in many programming languages of using all-upper-case identifiers for constants). Names beginning with double underscore or an underscore and a capital letter are reserved for implementation (compiler, standard library) and should not be used (e.g. __reserved or _Reserved).

Java language

• In Java, very strong conventions established from the beginning by the language's originators require classes and variables to be capitalised differently. Thus, to a Java programmer, widget.expand() and Widget.expand() imply significantly different behaviour, even without prior knowledge of the Widget class and despite the fact that the compiler enforces no such rules.

Visual Basic, VB.NET and BASIC languages

• Traditionally, Basic does not implement the mandatory case-sensitivity that the C-type languages do, and the IDE often provides on-the-spot variable identification. Hence Visual Basic naming conventions tend to rest on what is most human-readable, as opposed to providing information about the identifier itself. For instance, lpszMyString in C would just become MyString in Visual Basic, and widget.expand() would mean the same as Widget.expand(). VB.Net standards are based on framework-wide .Net standards that are shared among all .Net languages including C#, and are essentially the same as Visual Basic, being Pascal-cased with no type prefix hints.

Perl

• Perl takes some cues from its C heritage for conventions. Locally scoped variables and subroutine names are lowercase with infix underscores. Subroutines and variables meant to be treated as private are prefixed with an underscore. Package variables are title cased. Declared constants are all caps. Package names are camel case excepting pragmata—e.g., strict and mro—which are lowercase.

See also

• Namespace
• Namespace (computer science)

References

External links

• American Name Society Promote onomastics, the study of names and naming practices, both in the United States and abroad.
• Coding-guidelines.com has a 100-page pdf that uses linguistics and psychology to attempt a cost/benefit analysis of identifier naming issues
• Ontology Naming Conventions The application of unified labeling or naming conventions in ontology engineering will help to harmonize the appearance and increase the robustness of ontological representational units such as class and relation names within the orthogonal set of OBO Foundry ontologies.