In computer programming, a naming convention is a set of rules for choosing the character sequence to be used for identifiers which denote variables, types, functions, and other entities in source code and documentation.
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.
Well-chosen identifiers make it significantly easier for developers and analysts to understand what the system is doing and how to fix or extend the source code to apply for new needs.
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.
Brevity in programming could be in part attributed to: Some naming conventions limit whether letters may appear in uppercase or lowercase.
Consequently, some naming conventions specify rules for the treatment of "compound" identifiers containing more than one word.
The hyphen is used by nearly all programmers writing COBOL (1959), Forth (1970), and Lisp (1958); it is also common in Unix for commands and packages, and is used in CSS.
[5] This convention has no standard name, though it may be referred to as lisp-case or COBOL-CASE (compare Pascal case), kebab-case, brochette-case, or other variants.
Some naming conventions represent rules or requirements that go beyond the requirements of a specific project or problem domain, and instead reflect a greater overarching set of principles defined by the software architecture, underlying programming language or other kind of cross-project methodology.
A style used for very short (eight 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.
It detailed the PRIME-MODIFIER-CLASS word scheme, which consisted of names like "CUST-ACT-NO" to indicate "customer account number".
Common CLASS words might be: NO (number), ID (identifier), TXT (text), AMT (amount), QTY (quantity), FL (flag), CD (code), W (work) and so forth.
CLASS words, typically positioned on the right (suffix), served much the same purpose as Hungarian notation prefixes.
Adobe's Coding Conventions and Best Practices suggests naming standards for ActionScript that are mostly consistent with those of ECMAScript.
The guidelines further recommend that the name given to an interface be PascalCase preceded by the capital letter I, as in IEnumerable.
In the Dart language, used in the Flutter SDK, the conventions are similar to those of Java, except that constants are written in lowerCamelCase.
Java compilers do not enforce these rules, but failing to follow them may result in confusion and erroneous code.
One widely used Java coding style dictates that UpperCamelCase be used for classes and lowerCamelCase be used for instances and methods.
For instance, in Eclipse's content assist feature, typing just the upper-case letters of a CamelCase word will suggest any matching class or method name (for example, typing "NPE" and activating content assist could suggest NullPointerException).
[28] See also: Douglas Crockford's conventions Common practice in most Lisp dialects is to use dashes to separate words in identifiers, as in with-open-file and make-hash-table.
Top-level entities, including classes, protocols, categories, as well as C constructs that are used in Objective-C programs like global variables and functions, are in UpperCamelCase with a short all-uppercase prefix denoting namespace, like NSString, UIAppDelegate, NSApp or CGRectMake.
Method names use multiple lowerCamelCase parts separated by colons that delimit arguments, like: application:didFinishLaunchingWithOptions:, stringWithFormat: and isRunning.
Wirthian languages Pascal, Modula-2 and Oberon generally use Capitalized or UpperCamelCase identifiers for programs, modules, constants, types and procedures, and lowercase or lowerCamelCase identifiers for math constants, variables, formal parameters and functions.
Prefixing with double underscores changes behaviour in classes with regard to name mangling.
However a major update with Swift 3.0 stabilised the naming conventions for lowerCamelCase across variables and function declarations.