Global Variables Considered Harmful

Prof. William Wulf and Mary Shaw wrote a paper of this title in 1973, although I couldn't find the original paper online I did find some references.

Here are the key disadvantages:

  1. Side effects - hidden access
  2. Indiscriminant access - can't prevent access - may be difficult to make changes later
  3. Screening - may lose access via new declaration of variable
  4. Aliasing - control shared access to prevent more than one name for reference variables.

Backgound: I have been adding unit tests to existing stand-alone code to support refactoring and eventual migration to our current framework. The code is full of global variable references. Not only that, but work-arounds have been developed that depend on side effects caused by the use of a single global to mean more than one thing depending on which code ran last.

Because of all the things identified by Prof. Wulf I cannot be sure that if I change anything the code will still run as originally created. However, I must change things to make them testable. Luckily I do have access to other developers who have worked on the application (just fix the bug, don't change anything else) for some level of confidence about what is supposed to happen. Also, I don't have any refactoring tools (VB6) so all changes must be tediously made by hand with great attention to detail. What fun!


  • Global variables...What a subject!

    I'm currently working in VB6.

    I'm sure that there are times when a global var is better, easier to use than a local var that must be passed from one procedure to another to another...What a mess.

    When I find that I'm on my 5th proc or so I usually declare the var globally. I name the vars with gl prefix (global, long) so I know what I've done.

    Rather than "Don't do it." I'm looking for instances when global vars are best.

  • Global varaiables are "Evil" - if you really need the functionality of global variables, create a class (clsGlobals) and add all your globals into that class with property Get/Let (or Set) accesors.

    Then in a bas module create a single property Get (Not Set - keep the access to the gloabls object read only so you cant destroy it accidentaly) to access a single instance of the new globals class:

    8<------Put this in your bas module-----

    private m_objGlobals as New clsGlobals

    Public property get Globals() as clsGloabals

    Set Globals = m_objGlobals

    end Property


    Now from anyware within the project, you can access your global variables by:

    Gloabls.PropertyName = "x"

    This is preferable as you can now set break point on the property Let/Set within the globals class to easily catch when the values are being changed.

    This is similar to the "Singleton design pattern" and is very useful...

    just my thoughts

    joebourne at gmail dot com

  • I could not disagree more. One particular prudent use of a global variable is to hold a large data structure. If multiple routines need to be able to access that data, it's stupid and wasteful to pass it around from routine to routine.

    Object-oriented solutions are fine, but creating a class to replace your global variable is just moving the shell around the table. The ball is still under there. And you're just making it harder to understand.

    A global variable, and what it accomplishes, are very simple and elegant solutions to a particular problem. Everyone understands what they are doing and why. The same can NOT be said about replacing this functionality with a class.

Comments have been disabled for this content.