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 enable code reviews to focus on issues more important than syntax and naming standards.
To enable code quality review tools to focus their reporting mainly on significant issues other than syntax and style preferences.
The choice of naming conventions can be a 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 dogma.[2] Many companies have also established their own set of conventions.
Potential benefits
Benefits of a naming convention can include the following:
to provide additional information (i.e., 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);
to provide meaningful data to be used in project handovers which require submission of program source code and all relevant documentation;
to provide better understanding in case of code reuse after a long interval of time.
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.
Readability
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.
For example, although
a=b*c;
is syntactically correct, its purpose is not evident. Contrast this with:
weekly_pay=hours_worked*hourly_pay_rate;
which implies the intent and meaning of the source code, at least to those familiar with the context of the statement.
Experiments suggest that identifier style affects recall and precision and that familiarity with a style speeds recall.[3]
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
Fundamental elements 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 (although many IDEs and text-editors provide text-completion, which mitigates this)
extremely short identifiers (such as 'i' or 'j') are very difficult to uniquely distinguish using automated search and replace tools (although this is not an issue for regex-based 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 some 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 to save memory. A later "advance" allowed longer variable names to be used for human comprehensibility, but where only the first few characters were significant. In some versions of BASIC such as TRS-80 Level 2 Basic, long names were allowed, but only the first two letters were significant. This feature permitted erroneous behaviour that could be difficult to debug, for example when names such as "VALUE" and "VAT" were used and intended to be distinct.
early low-resolution monitors with limited line length (e.g. only 80 characters)
much of computer science originating from mathematics, where variable names are traditionally only a single letter
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.
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). Historically some early languages, notably FORTRAN (1955) and ALGOL (1958), allowed spaces within identifiers, determining the end of identifiers by context. This was abandoned in later languages due to the difficulty of tokenization. It is possible to write names by simply concatenating words, and this is sometimes used, as in mypackage for Java package names,[4] though legibility suffers for longer terms, so usually some form of separation is used.
Delimiter-separated words
One approach is to delimit separate words with a non-alphanumeric 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 (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.[6][7][8][9] Of these, kebab-case, dating at least to 2012,[10] has achieved some currency since.[11][12]
By contrast, languages in the FORTRAN/ALGOL tradition, notably languages in the C and Pascal families, used the hyphen for the subtractioninfix operator, and did not wish to require spaces around it (as free-form languages), preventing its use in identifiers.
An alternative is to use underscores; this is common in the C family (including Python), with lowercase words, being found for example in The C Programming Language (1978), and has come to be known as snake case or snail case. Underscores with uppercase, as in UPPER_CASE, are commonly used for C preprocessor macros, hence known as MACRO_CASE, and for environment variables in Unix, such as BASH_VERSION in bash. Sometimes this is humorously referred to as SCREAMING_SNAKE_CASE (alternatively SCREAMING_SNAIL_CASE).
Another approach is to indicate word boundaries using medial capitalization, called "camelCase", "PascalCase", and many other names, thus respectively rendering "two words" as "twoWords" or "TwoWords". This convention is commonly used in Pascal, Java, C#, and Visual Basic. Treatment of initialisms in identifiers (e.g. the "XML" and "HTTP" in XMLHttpRequest) varies. Some dictate that they be lowercase (e.g. XmlHttpRequest) to ease typing, readability and ease of segmentation, whereas others leave them uppercased (e.g. XMLHTTPRequest) for accuracy.
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.
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.[17] For example, the prefix "sz" for the variable szName indicates that the variable is a null-terminated string.
Positional notation
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.
This sort of convention is still in active use in mainframes dependent upon JCL and is also seen in the 8.3 (maximum eight characters with period separator followed by three character file type) MS-DOS style.
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
ActionScript
Adobe's Coding Conventions and Best Practices suggests naming standards for ActionScript that are mostly consistent with those of ECMAScript.[citation needed] The style of identifiers is similar to that of Java.
Ada
In Ada, the only recommended style of identifiers is Mixed_Case_With_Underscores.[18]
APL
In APL dialects, the delta (Δ) is used between words, e.g. PERFΔSQUARE (no lowercase traditionally existed in older APL versions). If the name used underscored letters, then the delta underbar (⍙) would be used instead.
C and C++
In C and C++, keywords and standard library identifiers are mostly lowercase. In the C standard library, abbreviated names are the most common (e.g. isalnum for a function testing whether a character is alphanumeric), while the C++ standard library often uses an underscore as a word separator (e.g. out_of_range). Identifiers representing macros are, by convention, written using only uppercase letters and underscores (this is related to the convention in many programming languages of using all-upper-case identifiers for constants). Names containing double underscore or beginning with an underscore and a capital letter are reserved for implementation (compiler, standard library) and should not be used (e.g. __reserved or _Reserved).[19][20] This is superficially similar to stropping, but the semantics differ: the underscores are part of the value of the identifier, rather than being quoting characters (as is stropping): the value of __foo is __foo (which is reserved), not foo (but in a different namespace).
C#
C# naming conventions generally follow the guidelines published by Microsoft for all .NET languages[21] (see the .NET section, below), but no conventions are enforced by the C# compiler.
The Microsoft guidelines recommend the exclusive use of only PascalCase and camelCase, with the latter used only for method parameter names and method-local variable names (including method-local const values). A special exception to PascalCase is made for two-letter acronyms that begin an identifier; in these cases, both letters are capitalized (for example, IOStream); this is not the case for longer acronyms (for example, XmlStream). The guidelines further recommend that the name given to an interface be PascalCase preceded by the capital letter I, as in IEnumerable.
The Microsoft guidelines for naming fields are specific to static, public, and protected fields; fields that are not static and that have other accessibility levels (such as internal and private) are explicitly not covered by the guidelines.[22] The most common practice is to use PascalCase for the names of all fields, except for those which are private (and neither const nor static), which are given names that use camelCase preceded by a single underscore; for example, _totalCount.
Any identifier name may be prefixed by the commercial-at symbol (@), without any change in meaning. That is, both factor and @factor refer to the same object. By convention, this prefix is only used in cases when the identifier would otherwise be either a reserved keyword (such as for and while), which may not be used as an identifier without the prefix, or a contextual keyword (such as from and where), in which cases the prefix is not strictly required (at least not at its declaration; for example, although the declaration dynamicdynamic; is valid, this would typically be seen as dynamic@dynamic; to indicate to the reader immediately that the latter is a variable name).
Dart/Flutter
In the Dart language, used in the Flutter SDK, the conventions are similar to those of Java, except that constants are written in lowerCamelCase. Dart imposes the syntactic rule that non-local identifiers beginning with an underscore (_) are treated as private (since the language does not have explicit keywords for public or private access). Additionally, source file names do not follow Java's "one public class per source file, name must match" rule, instead using snake_case for filenames.[23]
Go
In Go, the convention is to use MixedCaps or mixedCaps rather than underscores to write multiword names. When referring to structs or functions, the first letter specifies the visibility for external packages. Making the first letter uppercase exports that piece of code, while lowercase makes it only usable within the current scope.[24]
Java
In Java, naming conventions for identifiers have been established and suggested by various Java communities such as Sun Microsystems,[25] Netscape,[26] AmbySoft,[27] etc. A sample of naming conventions set by Sun Microsystems are listed below, where a name in "CamelCase" is one composed of a number of words joined without spaces, with each word's -- excluding the first word's -- initial letter in capitals – for example "camelCase".
Identifier type
Rules for naming
Examples
Classes
Class names should be nouns in UpperCamelCase, with the first letter of every word capitalised. Use whole words – avoid acronyms and abbreviations (unless the abbreviation is much more widely used than the long form, such as URL or HTML).
class Raster {}
class ImageSprite {}
Methods
Methods should be verbs in lowerCamelCase or a multi-word name that begins with a verb in lowercase; that is, with the first letter lowercase and the first letters of subsequent words in uppercase.
run();
runFast();
getBackground();
Variables
Local variables, instance variables, and class variables are also written in lowerCamelCase. Variable names should not start with underscore (_) or dollar sign ($) characters, even though both are allowed. This is in contrast to other coding conventions that state that underscores should be used to prefix all instance variables.
Variable names should be short yet meaningful. The choice of a variable name should be mnemonic — that is, designed to indicate to the casual observer the intent of its use. One-character variable names should be avoided except for temporary "throwaway" variables. Common names for temporary variables are i, j, k, m, and n for integers; c, d, and e for characters.
int i;
char c;
float myWidth;
Constants
Constants should be written in uppercase characters separated by underscores. Constant names may also contain digits if appropriate, but not as the first character.
staticfinalintMAX_PARTICIPANTS=10;
Java compilers do not enforce these rules, but failing to follow them may result in confusion and erroneous code. For example, widget.expand() and Widget.expand() imply significantly different behaviours: widget.expand() implies an invocation to method expand() in an instance named widget, whereas Widget.expand() implies an invocation to static method expand() in class Widget.
One widely used Java coding style dictates that UpperCamelCase be used for classes and lowerCamelCase be used for instances and methods.[25] Recognising this usage, some IDEs, such as Eclipse, implement shortcuts based on CamelCase. 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).
Initialisms of three or more letters are CamelCase instead of uppercase (e.g., parseDbmXmlFromIPAddress instead of parseDBMXMLFromIPAddress). One may also set the boundary at two or more letters (e.g. parseDbmXmlFromIpAddress).
JavaScript
The built-in JavaScript libraries use the same naming conventions as Java. Data types and constructor functions use upper camel case (RegExp, TypeError, XMLHttpRequest, DOMObject) and methods use lower camel case (getElementById, getElementsByTagNameNS, createCDATASection). In order to be consistent most JavaScript developers follow these conventions.[28] See also: Douglas Crockford's conventions
Lisp
Common practice in most Lisp dialects is to use dashes to separate words in identifiers, as in with-open-file and make-hash-table. Dynamic variable names conventionally start and end with asterisks: *map-walls*. Constants names are marked by plus signs: +map-size+.[29][30]
.NET
Microsoft .NET recommends UpperCamelCase, also known as PascalCase, for most identifiers. (lowerCamelCase is recommended for parameters and variables) and is a shared convention for the .NET languages.[31] Microsoft further recommends that no type prefix hints (also known as Hungarian notation) are used.[32] Instead of using Hungarian notation it is recommended to end the name with the base class' name; LoginButton instead of BtnLogin.[33]
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. Constants may optionally be prefixed with a lowercase letter "k" like kCFBooleanTrue.
Instance variables of an object use lowerCamelCase prefixed with an underscore, like _delegate and _tableView.
Method names use multiple lowerCamelCase parts separated by colons that delimit arguments, like: application:didFinishLaunchingWithOptions:, stringWithFormat: and isRunning.
Pascal, Modula-2 and Oberon
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.[34] While some dialects support underscore and dollar signs in identifiers, snake case and macro case is more likely confined to use within foreign API interfaces.[35]
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. [36][37]
PHP
PHP recommendations are contained in PSR-1 (PHP Standard Recommendation 1) and PSR-12.[38] According to PSR-1, class names should be in PascalCase, class constants should be in MACRO_CASE, and function and method names should be in camelCase.[39]
Python and Ruby
Python and Ruby both recommend UpperCamelCase for class names, CAPITALIZED_WITH_UNDERSCORES for constants, and snake_case for other names.
In Python, if a name is intended to be "private", it is prefixed by one or two underscores. Private variables are enforced in Python only by convention. Names can also be suffixed with an underscore to prevent conflict with Python keywords. Prefixing with double underscores changes behaviour in classes with regard to name mangling. Prefixing and suffixing with double underscores - the so-called "dunder" ("double under") methods in Python - are reserved for "magic names" which fulfill special behaviour in Python objects.[40]
R
While there is no official style guide for R, the tidyverse style guide from R-guru Hadley Wickham sets the standard for most users.[41] This guide recommends avoiding special characters in file names and using only numbers, letters and underscores for variable and function names e.g. fit_models.R.
Raku
Raku follows more or less the same conventions as Perl, except that it allows an infix hyphen - or an apostrophe ' (or single quote) within an identifier (but not two in a row), provided that it is followed by an alphabetic character. Raku programmers thus often use kebab case in their identifiers; for example, fish-food and don't-do-that are valid identifiers. [42]
Rust
Rust recommends UpperCamelCase for type aliases and struct, trait, enum, and enum variant names, SCREAMING_SNAKE_CASE for constants or statics and snake_case for variable, function and struct member names.[43]
Swift
Swift has shifted its naming conventions with each individual release. However a major update with Swift 3.0 stabilised the naming conventions for lowerCamelCase across variables and function declarations. Constants are usually defined by enum types or constant parameters that are also written this way. Class and other object type declarations are UpperCamelCase.
As of Swift 3.0 there have been made clear naming guidelines for the language in an effort to standardise the API naming and declaration conventions across all third party APIs. [44]
Camel case is the practice of writing phrases without spaces or punctuation and with capitalized words. The format indicates the first word starting with either case, then the following words having an initial uppercase letter. Common examples include YouTube, iPhone and eBay. Camel case is often used as a naming convention in computer programming. It is also sometimes used in online usernames such as JohnSmith, and to make multi-word domain names more legible, for example in promoting EasyWidgetCompany.com.
In mathematics and computing, the hexadecimal numeral system is a positional numeral system that represents numbers using a radix (base) of sixteen. Unlike the decimal system representing numbers using ten symbols, hexadecimal uses sixteen distinct symbols, most often the symbols "0"–"9" to represent values 0 to 9, and "A"–"F" to represent values from ten to fifteen.
Hungarian notation is an identifier naming convention in computer programming in which the name of a variable or function indicates its intention or kind, or in some dialects, its type. The original Hungarian notation uses only intention or kind in its naming convention and is sometimes called Apps Hungarian as it became popular in the Microsoft Apps division in the development of Microsoft Office applications. When the Microsoft Windows division adopted the naming convention, they based it on the actual data type, and this convention became widely spread through the Windows API; this is sometimes called Systems Hungarian notation.
In computers, case sensitivity defines whether uppercase and lowercase letters are treated as distinct (case-sensitive) or equivalent (case-insensitive). For instance, when users interested in learning about dogs search an e-book, "dog" and "Dog" are of the same significance to them. Thus, they request a case-insensitive search. But when they search an online encyclopedia for information about the United Nations, for example, or something with no ambiguity regarding capitalization and ambiguity between two or more terms cut down by capitalization, they may prefer a case-sensitive search.
In a computer language, a reserved word is a word that cannot be used as an identifier, such as the name of a variable, function, or label – it is "reserved from use". This is a syntactic definition, and a reserved word may have no user-defined meaning.
A string literal or anonymous string is a literal for a string value in the source code of a computer program. Modern programming languages commonly use a quoted sequence of characters, formally "bracketed delimiters", as in x = "foo", where "foo" is a string literal with value foo. Methods such as escape sequences can be used to avoid the problem of delimiter collision and allow the delimiters to be embedded in a string. There are many alternate notations for specifying string literals especially in complicated cases. The exact notation depends on the programming language in question. Nevertheless, there are general guidelines that most modern programming languages follow.
Capitalization or capitalisation is writing a word with its first letter as a capital letter and the remaining letters in lower case, in writing systems with a case distinction. The term also may refer to the choice of the casing applied to text.
An underscore or underline is a line drawn under a segment of text. In proofreading, underscoring is a convention that says "set this text in italic type", traditionally used on manuscript or typescript as an instruction to the printer. Its use to add emphasis in modern finished documents is generally avoided.
Letter case is the distinction between the letters that are in larger uppercase or capitals and smaller lowercase in the written representation of certain languages. The writing systems that distinguish between the upper- and lowercase have two parallel sets of letters: each in the majuscule set has a counterpart in the minuscule set. Some counterpart letters have the same shape, and differ only in size, but for others the shapes are different. The two case variants are alternative representations of the same letter: they have the same name and pronunciation and are typically treated identically when sorting in alphabetical order.
In compiler construction, name mangling is a technique used to solve various problems caused by the need to resolve unique names for programming entities in many modern programming languages.
In computer science, a relational operator is a programming language construct or operator that tests or defines some kind of relation between two entities. These include numerical equality and inequalities.
The iota subscript is a diacritic mark in the Greek alphabet shaped like a small vertical stroke or miniature iota ⟨ι⟩ placed below the letter. It can occur with the vowel letters eta ⟨η⟩, omega ⟨ω⟩, and alpha ⟨α⟩. It represents the former presence of an offglide after the vowel, forming a so‐called "long diphthong". Such diphthongs —phonologically distinct from the corresponding normal or "short" diphthongs —were a feature of ancient Greek in the pre-classical and classical eras.
In computer programming, a sigil is a symbol affixed to a variable name, showing the variable's datatype or scope, usually a prefix, as in $foo, where $ is the sigil.
The computer programming languages C and Pascal have similar times of origin, influences, and purposes. Both were used to design their own compilers early in their lifetimes. The original Pascal definition appeared in 1969 and a first compiler in 1970. The first version of C appeared in 1972.
In computer language design, stropping is a method of explicitly marking letter sequences as having a special property, such as being a keyword, or a certain type of variable or storage location, and thus inhabiting a different namespace from ordinary names ("identifiers"), in order to avoid clashes. Stropping is not used in most modern languages – instead, keywords are reserved words and cannot be used as identifiers. Stropping allows the same letter sequence to be used both as a keyword and as an identifier, and simplifies parsing in that case – for example allowing a variable named if without clashing with the keyword if.
In computer programming, an enumerated type is a data type consisting of a set of named values called elements, members, enumeral, or enumerators of the type. The enumerator names are usually identifiers that behave as constants in the language. An enumerated type can be seen as a degenerate tagged union of unit type. A variable that has been declared as having an enumerated type can be assigned any of the enumerators as a value. In other words, an enumerated type has values that are different from each other, and that can be compared and assigned, but are not specified by the programmer as having any particular concrete representation in the computer's memory; compilers and interpreters can represent them arbitrarily.
In computer programming, a variable is an abstract storage location paired with an associated symbolic name, which contains some known or unknown quantity of data or object referred to as a value; or in simpler terms, a variable is a named container for a particular set of bits or type of data. A variable can eventually be associated with or identified by a memory address. The variable name is the usual way to reference the stored value, in addition to referring to the variable itself, depending on the context. This separation of name and content allows the name to be used independently of the exact information it represents. The identifier in computer source code can be bound to a value during run time, and the value of the variable may thus change during the course of program execution.
In computer programming, a constant is a value that is not altered by the program during normal execution. When associated with an identifier, a constant is said to be "named," although the terms "constant" and "named constant" are often used interchangeably. This is contrasted with a variable, which is an identifier with a value that can be changed during normal execution. To simplify, constants' values remains, while the values of variables varies, both hence their names.
Snake case is the naming convention in which each space is replaced with an underscore (_) character, and words are written in lowercase. It is a commonly used naming convention in computing, for example for variable and subroutine names, and for filenames. One study has found that readers can recognize snake case values more quickly than camel case. However, "subjects were trained mainly in the underscore style", so the possibility of bias cannot be eliminated.
In computer programming languages, an identifier is a lexical token that names the language's entities. Some of the kinds of entities an identifier might denote include variables, data types, labels, subroutines, and modules.
coding-guidelines.com has a pdf that uses linguistics and psychology to attempt a cost/benefit analysis of identifier naming issues
This page is based on this Wikipedia article Text is available under the CC BY-SA 4.0 license; additional terms may apply. Images, videos and audio are available under their respective licenses.
