This article describes the standards that apply to variable names. All of the listed recommendations are mandatory unless noted otherwise. Show
1. Name your variables based on the terms of the subject area, so that the variable name clearly describes its purpose. 2. Create variable names by deleting spaces that separate the words. Capitalize each word in the name, including prepositions and pronouns that consist of a single letter. Example: Variable DirectoryProcessingDialog; // Dialog to work with a directory Variable PacksInBoxQuantity; // Number of packs in a box Examples of incorrect variable names: maxAttributes, matchTypeName, newStr 3. Do not begin variable names with an underscore. 4. Do not use variable names that consist of a single character. Short variable names are only allowed for loop counters. 5. Name variables that describe binary states ("true" or "false") after the state that matches the "true" value. Example: Variable HasErrors; // Shows whether procedure contains errors. Variable IsReusableContainer; // Shows whether a product is a reusable container. Next page: Writing register records See also:
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. Reasons for using a naming convention (as opposed to allowing programmers to choose any character sequence) include the following:
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 dogma.[2] Many companies have also established their own set of conventions. Potential benefits[edit]Some of the potential benefits that can be obtained by adopting a naming convention include the following:
Challenges[edit]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[edit]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 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] Common elements[edit]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[edit]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:
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:
Letter case and numerals[edit]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[edit]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 Delimiter-separated words[edit]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 " By contrast, languages in the FORTRAN/ALGOL tradition, notably languages in the C and Pascal families, used the hyphen for the subtraction infix 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. 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. Letter case-separated words[edit]Another
approach is to indicate word boundaries using medial capitalization, called "camelCase", "PascalCase", and many other names, thus respectively rendering " Examples of multiple-word identifier formats[edit]Multiple-word identifier formats
Metadata and hybrid conventions[edit]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[edit]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[edit]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. Composite word scheme (OF Language)[edit]IBM's "OF Language" was documented in an IMS (Information Management System) manual. 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[edit]ActionScript[edit]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[edit]In Ada, the only recommended style of identifiers is
APL[edit]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++[edit]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. C#[edit]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 The Microsoft guidelines for naming fields are specific to Any identifier name may be prefixed by the commercial-at symbol ( Go[edit]In Go, the convention is to use Java[edit]In Java, naming conventions for identifiers have been established and suggested by various Java communities such as Sun Microsystems,[24] Netscape,[25] AmbySoft,[26] 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".
Java compilers do not enforce these rules, but failing to follow them may result in confusion and erroneous code. For example, One widely used Java coding style dictates that Initialisms of three or more
letters are CamelCase instead of uppercase (e.g., JavaScript[edit]The built-in JavaScript libraries use the same naming conventions as Java. Data types
and constructor functions use upper camel case ( Lisp[edit]Common practice in most Lisp dialects is to use dashes to separate words in identifiers, as in .NET[edit]Microsoft .NET recommends Objective-C[edit]Objective-C has a common coding style that has its roots in Smalltalk . 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
Instance variables of an object use lowerCamelCase prefixed with an underscore, like Method names use multiple lowerCamelCase parts separated by colons that delimit arguments, like: Pascal, Modula-2 and Oberon[edit]Wirthian languages Pascal, Modula-2 and Oberon generally use Perl[edit]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., PHP[edit]PHP recommendations are contained in PSR-1 (PHP Standard Recommendation 1) and PSR-12.[37] 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.[38] Python and Ruby[edit]Python and Ruby
both recommend In Python, if a name is intended to be "private", it is prefixed by one or two underscores (in Python it's more or less a hack). 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.[39] R[edit]While there is no official style guide for R, the tidyverse style guide from R-guru Hadley Wickham sets the standard for most users.[40] 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[edit]Raku follows more or less the same conventions as Perl, except that it allows an infix hyphen
Rust[edit]Rust recommends Swift[edit]Swift has shifted its naming conventions with each individual release. However a major update with Swift 3.0 stabilised the naming conventions for 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. [43] See also[edit]
References[edit]
External links[edit]
Which of the following is a valid reason for giving variables meaningful names in a program?Which of the following is a valid reason for giving variables meaningful names in a program? A programmer will find it easier to read and understand the code since they will know what the variables represent.
What are the 4 types of variables in coding?Constants, global variables, class variables, instance variables, and local variables.
What is the use of variable important in the code?Variables play an important role in computer programming because they enable programmers to write flexible programs. Rather than entering data directly into a program, a programmer can use variables to represent the data. ... The opposite of a variable is a constant. Constants are values that never change.
What is a variable in code development?What is a variable? In programming, a variable is a value that can change, depending on conditions or on information passed to the program.
|