Content deleted Content added
→Examples of multiple-word identifier formats: “ALL_CAPS” is the traditional name for that naming convention, see e.g. https://science.jrank.org/programming/Naming_Conventions.html, https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Res-ALL_CAPS, https://gcc.gnu.org/codingconventions.html#C_Names. Tags: Mobile edit Mobile web edit |
Rescuing 2 sources and tagging 0 as dead.) #IABot (v2.0.9.5 |
||
| (45 intermediate revisions by 31 users not shown) | |||
Line 5:
Reasons for using a naming convention (as opposed to allowing [[programmer]]s to choose any character sequence) include the following:
* To reduce the effort needed to read and understand [[source code]];<ref>Derek M. Jones [http://www.knosof.co.uk/cbook/oprandname.pdf "Operand names influence operator precedence decisions"] An experiment investigating the effect of variable names on operator precedence selection</ref>
* To enable code reviews to focus on issues more important than [[Syntax (programming languages)|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
==Potential benefits==
* to provide additional information (i.e., [[metadata]]) about the use to which an identifier is put;
Line 42:
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.<ref>{{Cite
</ref>
Line 84:
====Delimiter-separated words====
One approach is to [[delimiter|delimit]] separate words with a [[alphanumeric|non-alphanumeric]] character. The two characters commonly used for this purpose are the [[hyphen]] ("-") and the [[underscore]] ("_"); e.g., the two-word name "<code>two words</code>" would be represented as "<code>two-words</code>" or "<code>two_words</code>".
One approach is to [[delimiter|delimit]] separate words with a [[alphanumeric|nonalphanumeric]] character. The two characters commonly used for this purpose are the [[hyphen]] ("-") and the [[underscore]] ("_"); e.g., the two-word name "<code>two words</code>" would be represented as "<code>two-words</code>" or "<code>two_words</code>". The hyphen is used by nearly all programmers writing [[COBOL]] (1959), [[Forth (programming language)|Forth]] (1970), and [[Lisp (programming language)|Lisp]] (1958); it is also common in [[Unix]] for commands and packages, and is used in [[Cascading Style Sheets|CSS]].<ref>{{cite web |title = CSS reference |website = [[Mozilla Developer Network]] |url = https://developer.mozilla.org/en-US/docs/Web/CSS/Reference |access-date=2016-06-18}}</ref> 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.<ref>{{Cite web | title = StackOverflow – What's the name for snake_case with dashes? | url = https://stackoverflow.com/questions/11273282/whats-the-name-for-snake-case-with-dashes }}</ref><ref>{{Cite web | title = Programmers – If this is camelCase what-is-this? | url = http://programmers.stackexchange.com/questions/104468/if-this-is-camelcase-what-is-this }}</ref><ref>{{Cite web | title = Camel_SNAKE-kebab | website = [[GitHub]] | url = https://github.com/qerub/camel-snake-kebab | date = September 2019 }}</ref><ref>[http://c2.com/cgi/wiki?UnderscoreVersusCapitalAndLowerCaseVariableNaming UnderscoreVersusCapitalAndLowerCaseVariableNaming]</ref> Of these, ''kebab-case'', dating at least to 2012,<ref>{{cite web |url=https://stackoverflow.com/posts/12273101/revisions |title=Revisions to jwfearn's answer to What's the name for dash-separated case? |date=5 September 2012 |author=jwfearn}}</ref> has achieved some currency since.<ref>''Living Clojure'' (2015), by Carin Meier, [https://books.google.com/books?id=b4odCAAAQBAJ&pg=PA91 p. 91]</ref><ref>[https://lodash.com/docs#kebabCase lodash: kebabCase]</ref>▼
▲
By contrast, languages in the FORTRAN/ALGOL tradition, notably languages in the [[C (programming language)|C]] and [[Pascal (programming language)|Pascal]] families, used the hyphen for the [[subtraction]] [[infix notation|infix]] operator, and did not wish to require spaces around it (as [[free-form language]]s), 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]]. Underscores with uppercase, as in UPPER_CASE, are commonly used for [[C preprocessor]] macros, hence known as MACRO_CASE, and for [[environment variable]]s in Unix, such as BASH_VERSION in [[bash (Unix shell)|bash]]. Sometimes this is humorously referred to as SCREAMING_SNAKE_CASE.▼
By contrast, languages in the FORTRAN/ALGOL tradition, notably languages in the [[C (programming language)|C]] and [[Pascal (programming language)|Pascal]] families, used the hyphen for the [[subtraction]] [[infix notation|infix]] operator, and did not wish to require spaces around it (as [[free-form language]]s), preventing its use in identifiers.
▲
====Letter case-separated words====
{{See also|Letter case#Special case styles}}
Another approach is to indicate word boundaries using medial capitalization, called "[[camelCase]]", "PascalCase", and many other names, thus respectively rendering "<code>two words</code>" as "<code>twoWords</code>" or "<code>TwoWords</code>". This convention is commonly used in [[Pascal (programming language)|Pascal]], [[Java (programming language)|Java]], [[C Sharp (programming language)|C#]], and [[Visual Basic]]. Treatment of initialisms in identifiers (e.g. the "[[XML]]" and "[[HTTP]]" in <code>[[XMLHttpRequest]]</code>) varies. Some dictate that they be
====Examples of multiple-word identifier formats====
Line 102 ⟶ 106:
|-
|<code>TWOWORDS</code>
|UPPERCASE, SCREAMINGCASE<ref name=":0" />
|-
|<code>twoWords</code>
Line 108 ⟶ 112:
|-
|<code>TwoWords</code>
|PascalCase, UpperCamelCase
|-
|<code>two_words</code>
|[[snake_case]], snail_case, pothole_case
|-
|<code>TWO_WORDS</code>
|ALL_CAPS, [[
|-
|<code>two_Words</code>
Line 165 ⟶ 169:
==Language-specific conventions==
===ActionScript===
Adobe's Coding Conventions and Best Practices suggests naming standards for [[ActionScript]] that are mostly consistent with those of [[ECMAScript]].<ref>{{
===Ada===
Line 174 ⟶ 178:
===C and C++===
In [[C (programming language)|C]] and [[C++]], [[keyword (computer programming)|keyword]]s and [[standard library]] identifiers are mostly lowercase. In the [[C standard library]], abbreviated names are the most common (e.g. <code>isalnum</code> for a function testing whether a character is alphanumeric), while the [[C++ standard library]] often uses an underscore as a word separator (e.g. <code>out_of_range</code>). Identifiers representing [[C preprocessor#Macro definition and expansion|macros]] are, by convention, written using only uppercase letters and underscores, for example <code>NULL</code> and <code>EINVAL</code> (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. <code>__reserved</code> or <code>_Reserved</code>).<ref>{{Cite web | title = ISO/IEC 9899:1999 Programming languages – C | publisher = ISO | url = http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=29237}}</ref><ref>{{Cite web | title = ISO/IEC 14882:2011 Information technology – Programming languages – C++ | publisher = ISO | url = http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=50372}}</ref> This is superficially similar to [[Stropping (syntax)|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 <code>__foo</code> is <code>__foo</code> (which is reserved), not <code>foo</code> (but in a different namespace).
===C#===
[[C Sharp (programming language)|C#]] naming conventions generally follow the guidelines published by Microsoft for all .NET languages<ref>{{Cite web | title = Naming Guidelines | date = 15 September 2021 | publisher = Microsoft | url = https://docs.microsoft.com/en-us/dotnet/standard/design-guidelines/capitalization-conventions}}</ref> (see the .NET section, below), but no conventions are enforced by the C# compiler.
The Microsoft guidelines recommend the exclusive use of only <code>[[CamelCase|PascalCase]]</code> and <code>[[camelCase]]</code>, with the latter used only for method parameter names and method-local variable names (including method-local <code>const</code> 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, <code>IOStream</code>); this is not the case for longer acronyms (for example, <code>XmlStream</code>). The guidelines further recommend that the name given to an <code>interface</code> be <code>PascalCase</code> preceded by the capital letter <code>I</code>, as in <code>IEnumerable</code>.
The Microsoft guidelines for naming fields are specific to <code>static</code>, <code>public</code>, and <code>protected</code> fields; fields that are not <code>static</code> and that have other accessibility levels (such as <code>internal</code> and <code>private</code>) are explicitly not covered by the guidelines.<ref>{{Cite web | title = Names of Type Members | date = 15 September 2021 | publisher = Microsoft | url = https://docs.microsoft.com/en-us/dotnet/standard/design-guidelines/names-of-type-members}}</ref> The most common practice is to use <code>PascalCase</code> for the names of all fields, except for those which are <code>private</code> (and neither <code>const</code> nor <code>static</code>), which are given names that use <code>camelCase</code> preceded by a single underscore; for example, <code>_totalCount</code>.
Any identifier name may be prefixed by the commercial-at symbol (<code>@</code>), without any change in meaning. That is, both <code>factor</code> and <code>@factor</code> 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 <code>for</code> and <code>while</code>), which may not be used as an identifier without the prefix, or a contextual keyword (such as <code>from</code> and <code>where</code>), in which cases the prefix is not strictly required (at least not at its declaration; for example, although the declaration <code>dynamic dynamic;</code> is valid, this would typically be seen as <code>dynamic @dynamic;</code> to indicate to the reader immediately that the latter is a variable name).
Line 229 ⟶ 233:
|-
|Constants
|Constants should be written in
|
* {{code|2=java|1=static final int MAX_PARTICIPANTS = 10;}}
Line 262 ⟶ 266:
===Pascal, Modula-2 and Oberon===
Wirthian languages Pascal, Modula-2 and Oberon generally use <code>Capitalized</code> or <code>UpperCamelCase</code> identifiers for programs, modules, constants, types and procedures, and <code>lowercase</code> or <code>lowerCamelCase</code> identifiers for math constants, variables, formal parameters and functions.<ref>[https://web.archive.org/web/20161008155209/http://modula-2.info/m2r10/pmwiki.php/Recommendations/NameConvention#Identifiers Modula-2 Name Convention]</ref> 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.<ref>
===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., <code>strict</code> and <code>
<ref>{{Cite web | title = Perl style guide | url = http://perldoc.perl.org/perlstyle.html }}</ref>
<ref>{{Cite web | title = perlmodlib – constructing new Perl modules and finding existing ones | url = http://perldoc.perl.org/perlmodlib.html }}</ref>
Line 275 ⟶ 279:
[[Python (programming language)|Python]] and [[Ruby (programming language)|Ruby]] both recommend <code>UpperCamelCase</code> for class names, <code>CAPITALIZED_WITH_UNDERSCORES</code> for constants, and <code>snake_case</code> for other names.
In Python, if a name is intended to be "[[private member|private]]", it is prefixed by one or two underscores
=== R ===
While there is no official style guide for [[R (programming language)|R]], the [[tidyverse]] style guide from R-guru Hadley Wickham sets the standard for most users.<ref name=tidyverse>[https://style.tidyverse.org/ Style Guide for RCode ]</ref> This guide recommends
Its predecessors S and S-PLUS did not allow underscores in variable and function names, but instead used the period as a delimiter. As a result, many base functions in R still have a period as delimiter e.g. as.data.frame().
Hidden objects can be created with the dot prefix e.g. .hidden_object. These objects do not appear in the global environment. The dot prefix is often used by package developers for functions that are purely internal and are not supposed to be used by end users. It is similar to the underscore prefix in Python.
===Raku===
| |||