 | This articleneeds additional citations forverification. Please helpimprove this article byadding citations to reliable sources. Unsourced material may be challenged and removed. Find sources: "Variable" high-level programming – news ·newspapers ·books ·scholar ·JSTOR(November 2009) (Learn how and when to remove this message) |
Inhigh-level programming, avariable is an abstract storage orindirection location paired with an associatedsymbolic name, which contains someknown orunknown quantity ofdata orobject referred to as avalue; or in simpler terms, a variable is a named container for a particular set of bits ortype of data (likeinteger,float,string, etc...) or undefined.[1] A variable can eventually be associated with or identified by amemory address. The variable name is the usual way toreference 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 computersource code can bebound to avalue duringrun time, and the value of the variable may thus change during the course ofprogram execution.[2][3][4][5]
Variables in programming may not directly correspond to the concept ofvariables in mathematics. The latter isabstract, having no reference to a physical object such as storage location. The value of a computing variable is not necessarily part of anequation orformula as in mathematics. Furthermore, the variables can also be constants if the value is defined statically. Variables incomputer programming are frequently given long names to make them relatively descriptive of their use, whereas variables in mathematics often have terse, one- or two-character names for brevity in transcription and manipulation.
A variable's storage location may be referenced by several different identifiers, a situation known asaliasing. Assigning a value to the variable using one of the identifiers will change the value that can be accessed through the other identifiers.
Compilers have to replace variables' symbolic names with the actual locations of the data. While a variable's name, type, and location often remain fixed, the data stored in the location may be changed during program execution.
Inimperativeprogramming languages, values can generally beaccessed orchanged at any time. Inpurefunctional andlogic languages, variables arebound to expressions and keep a single value during their entirelifetime due to the requirements ofreferential transparency. In imperative languages, the same behavior is exhibited by (named)constants (symbolic constants), which are typically contrasted with (normal) variables.
Depending on thetype system of a programming language, variables may only be able to store a specifieddata type (e.g.integer orstring). Alternatively, a datatype may be associated only with the current value, allowing a single variable to store anything supported by the programming language. Variables are the containers for storing the values.
Variables and scope:
An identifier referencing a variable can be used to access the variable in order to read out the value, or alter the value, or edit otherattributes of the variable, such as access permission,locks,semaphores, etc.
For instance, a variable might be referenced by the identifier "total_count" and the variable can contain the number 1956. If the same variable is referenced by the identifier "r" as well, and if using this identifier "r", the value of the variable is altered to 2009, then reading the value using the identifier "total_count" will yield a result of 2009 and not 1956.
If a variable is only referenced by a single identifier, that identifier can simply be calledthe name of the variable; otherwise, we can speak of it asone of the names of the variable. For instance, in the previous example the identifier "total_count" is the name of the variable in question, and "r" is another name of the same variable.
Thescope of a variable describes where in a program's text the variable may be used, while theextent (also calledlifetime) of a variable describes when in a program's execution the variable has a (meaningful) value. The scope of a variable affects its extent. The scope of a variable is actually a property of the name of the variable, and the extent is a property of the storage location of the variable. These should not be confused withcontext (also calledenvironment), which is a property of the program, and varies by point in the program's text or execution—seescope: an overview. Further,object lifetime may coincide with variable lifetime, but in many cases is not tied to it.
Scope is an important part of thename resolution of a variable. Most languages define a specificscope for each variable (as well as any other named entity), which may differ within a given program. The scope of a variable is the portion of the program's text for which the variable's name has meaning and for which the variable is said to be "visible". Entrance into that scope typically begins a variable's lifetime (as it comes into context) and exit from that scope typically ends its lifetime (as it goes out of context). For instance, a variable with "lexical scope" is meaningful only within a certain function/subroutine, or more finely within a block of expressions/statements (accordingly withfunction scope orblock scope); this is static resolution, performable at parse-time or compile-time. Alternatively, a variable withdynamic scope is resolved at run-time, based on a global bindingstack that depends on the specificcontrol flow. Variables only accessible within a certain functions are termed "local variables". A "global variable", or one with indefinite scope, may be referred to anywhere in the program.
Extent, on the other hand, is a runtime (dynamic) aspect of a variable. Eachbinding of a variable to a value can have its ownextent at runtime. The extent of the binding is the portion of the program's execution time during which the variable continues to refer to the same value or memory location. A running program may enter and leave a given extent many times, as in the case of aclosure.
Unless the programming language featuresgarbage collection, a variable whose extent permanently outlasts its scope can result in amemory leak, whereby the memory allocated for the variable can never be freed since the variable which would be used to reference it for deallocation purposes is no longer accessible. However, it can be permissible for a variable binding to extend beyond its scope, as occurs in Lispclosures and Cstatic local variables; when execution passes back into the variable's scope, the variable may once again be used. A variable whose scope begins before its extent does is said to beuninitialized and often has an undefined, arbitrary value if accessed (seewild pointer), since it has yet to be explicitly given a particular value. A variable whose extent ends before its scope may become adangling pointer and deemed uninitialized once more since its value has been destroyed. Variables described by the previous two cases may be said to beout of extent orunbound. In many languages, it is an error to try to use the value of a variable when it is out of extent. In other languages, doing so may yieldunpredictable results. Such a variable may, however, be assigned a new value, which gives it a new extent.
For space efficiency, a memory space needed for a variable may be allocated only when the variable is first used and freed when it is no longer needed. A variable is only needed when it is in scope, thus beginning each variable's lifetime when it enters scope may give space to unused variables. To avoid wasting such space, compilers often warn programmers if a variable is declared but not used.
It is considered good programming practice to make the scope of variables as narrow as feasible so that different parts of a program do not accidentally interact with each other by modifying each other's variables. Doing so also preventsaction at a distance. Common techniques for doing so are to have different sections of a program use differentname spaces, or to make individual variables "private" through eitherdynamic variable scoping orlexical variable scoping.
Many programming languages employ a reserved value (often namednull ornil) to indicate an invalid or uninitialized variable.
Instatically typed languages such asC,C++,Java orC#, a variable also has atype, meaning that only certain kinds of values can be stored in it. For example, a variable of type "integer" is prohibited from storing text values.[6]
Indynamically typed languages such asPython, a variable's type is inferred by its value, and can change according to its value. InCommon Lisp, both situations exist simultaneously: A variable is given a type (if undeclared, it is assumed to beT, the universalsupertype) which exists at compile time. Values also have types, which can be checked and queried at runtime.
Typing of variables also allowspolymorphisms to be resolved at compile time. However, this is different from the polymorphism used in object-oriented function calls (referred to asvirtual functions inC++) which resolves the call based on the value type as opposed to the supertypes the variable is allowed to have.
Variables often store simple data, like integers and literal strings, but some programming languages allow a variable to store values of otherdatatypes as well. Such languages may also enable functions to beparametric polymorphic. These functions operate like variables to represent data of multiple types. For example, a function namedlength may determine the length of a list. Such alength function may be parametric polymorphic by including a type variable in itstype signature, since the number of elements in the list is independent of the elements' types.
Theformal parameters (orformal arguments) of functions are also referred to as variables. For instance, in thisPython code segment,
defadd_two(x:int)->int:returnx+2print(add_two(5))# prints: 7
the variable namedx is aparameter because it is given a value when the function is called. The integer 5 is theargument which givesx its value. In most languages, function parameters have local scope. This specific variable namedx can only be referred to within theadd_two function (though of course other functions can also have variables calledx).
The specifics of variable allocation and the representation of their values vary widely, both among programming languages and among implementations of a given language. Many language implementations allocate space forlocal variables, whose extent lasts for a single function call on thecall stack, and whose memory is automatically reclaimed when the function returns. More generally, inname binding, the name of a variable is bound to the address of some particular block (contiguous sequence) of bytes in memory, and operations on the variable manipulate that block.Referencing is more common for variables whose values have large or unknown sizes when the code is compiled. Such variables reference the location of the value instead of storing the value itself, which is allocated from a pool of memory called theheap.
Bound variables have values. A value, however, is an abstraction, an idea; in implementation, a value is represented by somedata object, which is stored somewhere in computer memory. The program, or theruntime environment, must set aside memory for each data object and, since memory is finite, ensure that this memory is yielded for reuse when the object is no longer needed to represent some variable's value.
Objects allocated from the heap must be reclaimed—especially when the objects are no longer needed. In agarbage-collected language (such asC#,Java, Python, Golang andLisp), the runtime environment automatically reclaims objects when extant variables can no longer refer to them. In non-garbage-collected languages, such asC, the program (and the programmer) must explicitlyallocate memory, and then later free it, to reclaim its memory. Failure to do so leads tomemory leaks, in which the heap is depleted as the program runs, risks eventual failure from exhausting available memory.
When a variable refers to adata structure created dynamically, some of its components may be only indirectly accessed through the variable. In such circumstances, garbage collectors (or analogous program features in languages that lack garbage collectors) must deal with a case where only a portion of the memory reachable from the variable needs to be reclaimed.
Unlike their mathematical counterparts, programming variables and constants commonly take multiple-character names, e.g.COST ortotal. Single-character names are most commonly used only for auxiliary variables; for instance,i,j,k forarray index variables.
Some naming conventions are enforced at the language level as part of the language syntax which involves the format of valid identifiers. In almost all languages, variable names cannot start with a digit (0–9) and cannot contain whitespace characters. Whether or not punctuation marks are permitted in variable names varies from language to language; many languages only permit theunderscore ("_") in variable names and forbid all other punctuation. In some programming languages,sigils (symbols or punctuation) are affixed to variable identifiers to indicate the variable's datatype or scope.
Case-sensitivity of variable names also varies between languages and some languages require the use of a certain case in naming certain entities;[note 1] Most modern languages are case-sensitive; some older languages are not. Some languages reserve certain forms of variable names for their own internal use; in many languages, names beginning with two underscores ("__") often fall under this category.
However, beyond the basic restrictions imposed by a language, the naming of variables is largely a matter of style. At themachine code level, variable names are not used, so the exact names chosen do not matter to the computer. Thus names of variables identify them, for the rest they are just a tool for programmers to make programs easier to write and understand. Using poorly chosen variable names can make code more difficult to review than non-descriptive names, so names that are clear are often encouraged.[7][8]
Programmers often create and adhere to code style guidelines that offer guidance on naming variables or impose a precise naming scheme. Shorter names are faster to type but are less descriptive; longer names often make programs easier to read and the purpose of variables easier to understand. However, extreme verbosity in variable names can also lead to less comprehensible code.
We can classify variables based on their lifetime. The different types of variables are static, stack-dynamic, explicit heap-dynamic, and implicit heap-dynamic. Astatic variable is also known as global variable, it is bound to a memory cell before execution begins and remains to the same memory cell until termination. A typical example is the static variables in C and C++. A Stack-dynamic variable is known as local variable, which is bound when the declaration statement is executed, and it is deallocated when the procedure returns. The main examples are local variables in C subprograms and Java methods. Explicit Heap-Dynamic variables are nameless (abstract) memory cells that are allocated and deallocated by explicit run-time instructions specified by the programmer. The main examples are dynamic objects in C++ (via new and delete) and all objects in Java. Implicit Heap-Dynamic variables are bound to heap storage only when they are assigned values. Allocation and release occur when values are reassigned to variables. As a result, Implicit heap-dynamic variables have the highest degree of flexibility. The main examples are some variables in JavaScript, PHP and all variables in APL.
