Problems With Global Variables
are not limited to one particular routine, they can be used
throughout the entire program. Some variables, whose scope is
more than just local, are carelessly referred to as global, even
though they are not. For example module variables are accessible
anywhere in a file. However, they are not available all the way
through the entire program, so they do not qualify as being
global. Most experts agree that global variables can be
convenient, but also put the programmer at risk for a variety of
changes to the global data - you may set the value of a global
variable in one place then call a function that changes its value.
Because the value is changed in a different function possibly
even in another file, you may not notice that it has been altered.
The error comes when the variable is used later under the
assumption it has not changed.
Accidental aliasing - 'Aliasing' is when one variable is referred to by more than one name. This mistake happens when a global variable is also used directly by a function, and then the same global variable is used as a parameter in the function call. When this happens the input variable and the global variable have the same memory address, and any changes to one will change the other.
See an example of the aliasing problem: In C In C++
And the Fix: In C In C++
Re-entrant code - Many recent operating systems allow code to be entered by more than one thread of control. This permits more than instance of a program to run simultaneously, and it is possible for different copies of the same program to share the same global data.
Obstruction of code reuse - Ideally a function, routine, or module should portable. Meaning the code can be cut and paste into another program without problems. However, a routine that uses global data is dependent on those variables. Either the routine will need to be remodelled to eliminate this dependence (which is the best solution), or the new program will have to be amended to include the necessary global variables.
manageability - The purpose of modularization is that a complex
program can be separated into a series of separate, smaller, and
more manageable problems. Using global data blurs the separating
and forces the programmer to mentally keep track of all uses of a
variable that is used throughout hundreds or thousands of lines
global values - Data that applies to the whole program, like
variables that indicate the state of a program (for example a
variable that designates Normal execution/Debug mode) can be
declared as global. Also, data that is needed all through the
program (like a data table used in every routine).
Alternatives for named constants - Global data can be used as a substitute for literal constants, and named constants (when not supported by the language being used. Use global variables like TRUE and FALSE to replace 0 and 1; also define MAX_ARRAY_SIZE = 100, and use MAX_ARRAY_SIZE to replace 100.
Simplifying use of very frequent data - When a variable appears in the parameter list of nearly every routine, it may be easier to make the variable global and remove it from the parameter lists.
Reducing tramp data - Data passed into a routine that is only needed as a parameter for another function called by the original routine is called 'Tramp' data. Once again make the variable global and remove it from the parameter lists.
new variable as a local variable, and only make it global if
absolutely necessary. Try making it a module variable before
-Use a naming convention that makes global variables conspicuous (G_var, Var_g)
-Make a detailed list of all global variables, indicating where it is used, and what it is used for.
global data members of an ADT can be made local, if accessor and
mutater functions are added.
Advantages of access routines:
-Centralized control - a change to the data structure that involves, only changes to the access routines, instead of many scattered references over the entire program code.
-Allows fire-walling and information hiding.
-Permits error checking.
Reference: Code Complete, Steve McConnell, Microsoft Press (1993).
Prepared by: Melvin Lenz, Chantal Laplante, Graeme Humphries, Chris Mills
Last Modified: June 6th, 2000
The content of this page was edited by Allan Caine, Laura Drever, Gorana Jankovic, Megan King, and Marie Lewis.
Copyright 2000 Department of Computer Science, University of Regina.
[CS Dept Home Page]