In mathematics, variables are used as placeholders for values that aren’t necessarily known. For example, in the equation,
x = 3y + 5
the variables x and y represent numbers that can take on a number of different values.Similarly, in a computer program, we also use variables to store values. A variable is
essentially a memory location in which a value can be stored.Typically, a variable is referred to by a name or identifier (like x, y, z in mathematics). In mathematics variables are usually used to hold numerical values.
However, in programming, variables can usually hold different types of values such as numbers, strings (a collection of characters),Booleans (true or false values), or more complex types such as arrays or objects.Naming Rules & Conventions
Most programming languages have very specific rules as to what you can use as variable identifiers (names). For example, most programming languages do not allow you to use
whitespace characters (space, tab, etc.) in a variable’s identifier. Allowing spaces would make variable names ambiguous: where does the variable’s name end and the rest of the program continue? How could you tell the difference between “average score” and two separate variables named “average” and “score”? Many programming languages also have reserved words–words or terms that are used by the programming language itself
and have special meaning.
Variable names cannot be the same as any reserved word as the language wouldn’t be able to distinguish between them.For similar reasons, many programming languages do not allow you to start a variable
name with a number as it would make it more difficult for a compiler or interpreter to parse a program’s source code. Yet other languages require that variables begin with a
specific character (PHP for example requires that all variables begin with a dollar sign, $ ).
In general, most programming languages allow you to use a combination of uppercase A-Z and lowercase a-z letters as well as numbers, [0-9] and certain special characters such as underscores _ or dollar signs, $ . Moreover, most programming languages (like
English) are case sensitive meaning that a variable name using lowercase letters is not the same variable as one that uses uppercase letters.
For example, the variables x and
X are different; the variables average , Average and AVERAGE are all different as well.
A few languages are case-insensitive meaning that they do not recognize differences in lower and uppercase letters when used in variable identifiers. Even in these languages,however, using a mixture of lowercase and uppercase letters to refer to the same variable is discouraged: it is difficult to read, inconsistent, and just plain ugly.Beyond the naming rules that languages may enforce, most languages have established naming conventions; a set of guidelines and best-practices for choosing identifier names for variables (as well as functions, methods, and class names).Conventions may be
widely adopted on a per-language basis or may be established within a certain library,framework or by an organization that may have official style guides. Naming conventions
are intended to give source code consistency which ultimately improves readability and makes it easier to understand. Following a consistent convention can also greatly reduce the chance for errors and mistakes. Good naming conventions also has an aesthetic appeal; code should be beautiful.
There are several general conventions when it comes to variables. An early convention,but still in common use is underscore casing in which variable names consisting of more than one word have words separated by underscore characters with all other characters being lowercase. For example:
average_score , number_of_students , miles_per_hour
A variation on this convention is to use all uppercase letters such as MILES_PER_HOUR .A more modern convention is to use lower camel casing (or just camel casing) in which
variable names with multiple words are written as one long word with the first letter in each new word capitalized but with the first word’s first letter lowercase.
averageScore , numberOfStudents , milesPerHour
The convention refers to the capitalized letters resembling the humps of a camel. One advantage that camel casing has over underscore casing is that you’re not always straining to type the underscore character. Yet another similar convention is upper camel casing,
also known as PascalCase1 which is like camel casing, but the first letter in the first word is also capitalized:AverageScore , NumberOfStudents , MilesPerHour
Each of these conventions is used in various languages in different contexts which we’ll explore more fully in subsequent sections (usually underscore lowercasing and camel casing are used to denote variables and functions, PascalCase is used to denote user defined types such as classes of structures, and underscore uppercasing is used to denotestatic and constant variables).However, for our purposes, we’ll use lower camel casing for variables in our pseudocode.Rarely, this is referred to as DromedaryCase; a Dromedary is an Arabian camel.There are exceptions and special cases to each of these conventions such as when a variable
name involves an acronym or ahyphenated word, etc. In such cases sensible extensions or compromises are employed. For example, xmlString or priorityXMLParser (involving the acronym Extensible Markup Language (XML)) may be used which keep all letters in the acronym consistent (all lowercase or all uppercase).In addition to these conventions, there are several best-practice principles when deciding on identifiers.
Be descriptive, but not verbose – Use variable names that describe what the
variable represents. The examples above,averageScore ,numberOfStudents ,milesPerHour clearly indicate what the variable is intended to represent. Using good, descriptive names makes it your code self-documenting (a reader can make
sense of it without having to read extensive supplemental documentation).
Avoid meaningless variable names such as value , aVariable , or some cryptic combination of v10 (its the 10th variable I’ve used!). Ambiguous variables such as name should also be avoided unless the context makes its clear what you are referring to (as when used inside of a Person object).
Single character variables are commonly used, but used in a context in which their meaning is clearly understood. For example, variable names such as x , y are okay
if they are used to refer to points in the Euclidean plane. Single character variables such as i , j are often used as index variables when iterating over arrays. In this case, terseness is valued over descriptiveness as the context is very well understood.
As a general rule, the more a variable is used, the shorter it should be. For
example, the variable numStudents may be preferred over the full variable numberOfStudents .
Avoid abbreviations (or at least use them sparingly) – You’re not being charged by the character in your code; you can afford to write out full words. Abbreviations can help to write shorter variable names, but not all abbreviations are the same. The
word “abbreviation” itself could be abbreviated as “abbr.”, “abbrv.” or “abbrev.”
for example. Abbreviations are not always universally understood by all users,may be ambiguous and non-standard. Moreover, modern IDEs provide automatic code completion, relieving you of the need to type longer variable names. If the
abbreviation is well-known or understood from context, then it may make sense to use it.
Avoid acronyms (or at least use them sparingly) – Using acronyms in variable names come with many of the same problems as abbreviations. However, if it makes sense in the context of your code and has little chance of being misunderstood or
mistaken, then go for it. For example,in the context of a financial application,APR (Annual Percentage Rate) would be a well-understood acronym in which case the variable apr may be preferred over the longer annualPercentageRate .
Avoid pluralizations, use singular forms – English is not a very consistent language when it comes to rules like pluralizations. For most cases you simply add “s”; for
others you add “es” or change the “y” to “i” and add “es”. Some words are the same form for singular and plural such as “glasses.”2 Other words have completely different forms (“focus” becomes “foci”). Still yet there are instances in which multiple words are acceptable: the plural of “person” can be “persons” or “people”.
Avoiding plural forms keeps things simple and consistent: you don’t need to be a grammarian in order easily read code. One potential exception to this is when using a collection such as an array to hold more than one element or the variable represents a quantity that is pluralized (as with numberOfStudents above).Though the guidelines above provide a good framework from which to write good variable names, reasonable people can and do disagree on best practice because at some point as you go from generalities to specifics, conventions become more of a matter of personal
preference and subjective aesthetics. Sometimes an organization may establish its own coding standards or style guide that must be followed which of course trumps any of the
In the end, a good balance must be struck between readability and consistency. Rules and conventions should be followed, until they get in the way of good code that is.