Prof. Norm Matloff
University of California, Davis
Davis, CA 95616
matloff@cs.ucdavis.edu
Long ago someone happened to make a statement to the effect that global variables can in some cases have some undesirable effects. Unfortunately, many teachers of beginning programming courses, as well as quite a few practicing programmers, then blindly followed like sheep, stating that one should almost never use global variables. This attitude goes way too far, much further than had originally been intended, and much of the reasoning behind it really doesn't make sense.
The anti-globalists will say, for example, "If you use global variables, it is hard to tell at what points in your code a variable's value might be changed. It is much clearer to declare the variable as local, say in main(), and then use it as a parameter in function calls." This may sound good at first, but let's take a closer look.
First, the statement itself is debatable. Following a sequence of parameters through a chain of several nested function calls isn't so easy either, whereas if the variable is global one can usually find it at the top of the main code file or similar spot.
But much more significantly, the same people who make the above objection mysteriously have no problem with "global" use of member variables in object-oriented languages. A member variable in a class is accessible to all member functions in the class. In other words, the variable is "global" to all the functions in the class. If a member function accesses the member variable directly, i.e. not via parameters, then this is exactly the same situation that the "anti-globalists" decry.
Consider, for example, the textbook "C++ Program Design," by Cohoon and Davidson. On p.255, they sternly advise the reader to avoid globals, citing the "global side effects" argument described above. Yet on pp.686ff, the authors' capstone project of the book, does exactly what the authors feel is such poor style. The class here, Bug, includes a member variable HitsTaken, which is modified within the member function IsHit() without being a parameter to that function.
Similarly, the anti-globalists say, "Global variables are bad because of the potential confusion which could arise if (accidentally or deliberately) has a local variable of the same name." True, but again this applies equally well to member variables in the OOP context, and yet the anti-globalists have no problem in using OOP.
Granted, there is a difference of degree. The scope of a global variable is broader than that of member variable. Nevertheless, the problems are identical, and in a large, complex class the degree of "trouble" caused would be just as serious.
Starting around 1995 or so, threaded programming became very popular, e.g. for Web and GUI applications. Threads are like stripped-down OS processes, but with one major difference being that communication between threads is usually handled via shared global variables. In other words, globals are necessities in threaded programming.
And now that multiprocessor systems have become commonplace in business contexts, and even affordable for home use, it must be pointed out that the shared-memory paradigm for parallel programming is considered the clearest way to write parallel applications--and the shared memory consists of global variables. So globals are necessities in shared-memory parallel programming.
There are at least two advantages from a debugging point of view to implementing a variable as a global: