Problems With Global Variables
Acceptable Uses
Guidelines
Access Routines
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
errors.
Unintentional
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.
Intellectual
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
of code.
Keeping
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.
-Create each
new variable as a local variable, and only make it global if
absolutely necessary. Try making it a module variable before
going global.
-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.
Most often
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.