Open main menu
Home
Random
Recent changes
Special pages
Community portal
Preferences
About Wikipedia
Disclaimers
Incubator escapee wiki
Search
User menu
Talk
Dark mode
Contributions
Create account
Log in
Editing
Scope (computer science)
(section)
Warning:
You are not logged in. Your IP address will be publicly visible if you make any edits. If you
log in
or
create an account
, your edits will be attributed to your username, along with other benefits.
Anti-spam check. Do
not
fill this in!
== Overview == {{see also|Variable (programming)#Scope and extent}} When discussing scope, there are three basic concepts: ''scope,'' ''extent,'' and ''context.'' "Scope" and "context" in particular are frequently confused: scope is a property of a name binding, while context is a property of a part of a program, that is either a portion of source code (''lexical context'' or ''static context'') or a portion of [[Run time (program lifecycle phase)|run time]] (''execution context,'' ''runtime context,'' ''calling context'' or ''dynamic context''). Execution context consists of lexical context (at the current execution point) plus additional runtime state such as the [[call stack]].{{efn|For [[self-modifying code]] the lexical context itself can change during run time.}} Strictly speaking, during execution a program enters and exits various name bindings' scopes, and at a point in execution name bindings are "in context" or "not in context", hence name bindings "come into context" or "go out of context" as the program execution enters or exits the scope.{{efn|By contrast, *"a name binding's context", *"a name binding coming into scope" or *"a name binding going out of scope" are all incorrect—a name binding has scope, while a part of a program has context.}} However, in practice usage is much looser. Scope is a source-code level concept, and a property of name bindings, particularly variable or function name bindings—names in the source code are [[Reference (computer science)|references]] to entities in the program—and is part of the behavior of a compiler or interpreter of a language. As such, issues of scope are similar to [[Pointer (computer programming)|pointers]], which are a type of reference used in programs more generally. Using the value of a variable when the name is in context but the variable is uninitialized is analogous to dereferencing (accessing the value of) a [[wild pointer]], as it is undefined. However, as variables are not destroyed until they go out of context, the analog of a [[dangling pointer]] does not exist. For entities such as variables, scope is a subset of [[object lifetime|lifetime]] (also known as [[Variable (programming)#Scope and extent|extent]])—a name can only refer to a variable that exists (possibly with undefined value), but variables that exist are not necessarily visible: a variable may exist but be inaccessible (the value is stored but not referred to within a given context), or accessible but not via the given name, in which case it is not in context (the program is "out of the scope of the name"). In other cases "lifetime" is irrelevant—a label (named position in the source code) has lifetime identical with the program (for statically compiled languages), but may be in context or not at a given point in the program, and likewise for [[static variable]]s—a [[static global variable]] is in context for the entire program, while a [[static local variable]] is only in context within a function or other local context, but both have lifetime of the entire run of the program. Determining which entity a name refers to is known as [[Name resolution (programming languages)|name resolution]] or [[name binding]] (particularly in [[object-oriented programming]]), and varies between languages. Given a name, the language (properly, the compiler or interpreter) checks all entities that are in context for matches; in case of ambiguity (two entities with the same name, such as a global and local variable with the same name), the name resolution rules are used to distinguish them. Most frequently, name resolution relies on an "inner-to-outer context" rule, such as the Python LEGB (Local, Enclosing, Global, Built-in) rule: names implicitly resolve to the narrowest relevant context. In some cases name resolution can be explicitly specified, such as by the <code>global</code> and <code>nonlocal</code> keywords in Python; in other cases the default rules cannot be overridden. When two identical names are in context at the same time, referring to different entities, one says that ''[[name masking]]'' is occurring, where the higher-priority name (usually innermost) is "masking" the lower-priority name. At the level of variables, this is known as [[variable shadowing]]. Due to the potential for [[logic error]]s from masking, some languages disallow or discourage masking, raising an error or warning at compile time or run time. Various [[programming language]]s have various different scope rules for different kinds of declarations and names. Such scope rules have a large effect on [[Formal semantics of programming languages|language semantics]] and, consequently, on the behavior and correctness of programs. In languages like [[C++]], accessing an unbound variable does not have well-defined semantics and may result in [[undefined behavior]], similar to referring to a [[dangling pointer]]; and declarations or names used outside their scope will generate [[syntax error]]s. Scopes are frequently tied to other language constructs and determined implicitly, but many languages also offer constructs specifically for controlling scope.
Edit summary
(Briefly describe your changes)
By publishing changes, you agree to the
Terms of Use
, and you irrevocably agree to release your contribution under the
CC BY-SA 4.0 License
and the
GFDL
. You agree that a hyperlink or URL is sufficient attribution under the Creative Commons license.
Cancel
Editing help
(opens in new window)