Scope

The most important characteristic of a variable is the scope of its name.

Scope refers to the section of the program that a variable name can be relied upon to label the same unit of storage.

In more technical language the scope is the part of the program were the name is bound to the same entity. 

There is also the subtle point of what we mean by "part of the program".  The simplest definition is some unit of code that is marked out in the program's text - i.e. block of text, a function or a module say. This corresponds to the most common definition of scope - lexical scope. 

For example, if you use a variable called A in a function and a variable called A in another function- it is clear that they share the same names but do they share the same values?

If the scope of the name A includes both functions then they do share the same values. If the scope of each name is restricted to the individual functions then they are different variables that just happen to have the same name.

Again more technically you could say that the names are the same but the bindings are different. 

One of the problems at this point in the discussion is that some programmers will never have encountered the idea of scope because many languages try and make things as simple as possible - so simple that the idea never occurs beyond the basics. 

For example in most scripting languages the natural way to work is to have  every variable that you define available for use throughout the program. In this case the variables are said to be "global" and the scope of a global variable is the entire program. In this case scope is an almost trivial concept. 

Globals and locals

Programming using nothing but global variables is fine until you start writing large programs and using functions or other types of module.

Once you break a large program down into functions or methods then the pay off is that you can write each as if it was a completely separate program.

Well you can as long as every variable that you use isn't a global variable.

If you have to worry about what names you can use for a variable while writing a function, because the name might have already been used in another function, then it is as bad as writing the program in one chunk.

For example, most programmers tend to use i and j for loop indices - to understand why you need to go back to the days of Fortran. If every variable is global then it's only a matter of time before an i or a j used in one function collides with their use in another function. This sort of name collision is the reason we don't like global variables.

The solution is to use local variables.

Local variables, are confined in scope to the function or method that declares them. For example, if you define Local A in one function and Local A in another function then the A in the first function has nothing to do with the A in the second function- they are different variables that just happen to share the same name.

If you are building a modular program then all of the variables within each module should be Local. How then do the modules communicate?

The answer is only by passing data using parameters.

Parameters are another story and to avoid getting side tracked I will assume that everyone knows what a parameter is and how they work. Parameters have a lot of devious traps waiting to get the careless programmer, but for the purpose of talking about variables these will also be ignored.

So what are global variables for if every variable in a module should be local to that module and if data is to be passed using parameters?

One answer is that global variables aren't for anything they are just a leftover from the days when we didn't know better.

An alternative answer is that passing every item of data that a module needs is boring, error prone and results in procedure calls the length of War and Peace.

Rather than pass every variable to a module it makes good sense to define the major items of data as global and allow every program to access them using the same name. After all if you have an array called TOTALS it is usually called TOTALS in all of the procedures that use it even if it is passed in as a parameter! In this sense the array is being treated as if it was a global variable even though it is local to each procedure.

The difficulty with this approach is how to draw the dividing line between what should be global and local. At its extreme it results in everything that might be passed as a parameter being declared as global and every procedure call consists of just the name of the procedure!

In other words, using local variables results in long parameter lists and using global variable results in no parameter lists.

Both approaches have their problems but today the emphasis falls on the need to decouple the modules that make up a program and hence local is always better than global.

In short - avoid global variables.