Fog Creek Software
Discussion Board

Globals Suck

My rant du jour...  Globals Suck.

Unbounded Scope == Unbounded Dependencies

Undocumented Globals suck worse:  Unbounded dependencies written by someone who doesn't think its a problem.

One bullet, just one bullet...

Nat Ersoz
Tuesday, January 28, 2003

bad week, eh Nat!

Prakash S
Tuesday, January 28, 2003

I worked with a guy who didn't even know variables could be local. Everything was global.

That was bad enough, but what really galled me is that he told everyone that he "wrote perfect code". I'm not kidding....No matter what I told him about the dangers of globals he insisted that he knew more about programming because he taught a class the local junior college and he believed globals were the proper way to use variables.

Mark Hoffman
Tuesday, January 28, 2003


Long live Bill the Cat.

Nat Ersoz
Tuesday, January 28, 2003

I'm currently upgrading an ancient vb3 appliication to vb6, I think it was written in 1992 (good ole days). It only uses globals, yesterday I removed 1210 unused global variables and/or api function declarations, to make matters worse, no variables are typed, everything is variant.

Tuesday, January 28, 2003

COincidently, this application has been in production for 10 years, and everybody loves it. Go figure.

Tuesday, January 28, 2003

Ah... the bitter taste of "global soup". Not my favorite flavor either. :)

Tuesday, January 28, 2003

Well, Alberto, I guess the one good thing you can say about the system is that apparently the system requirements seem to be on target, though implemented poorly.

sure points out, though, how tough it can be to get support for making improvements the user doesn't see (or probably care about) **sigh**

Tuesday, January 28, 2003

Actually, the rule for global is very simple:

    When you need them, use them!

Most of the time global can be avoided. Most of the time using globals is a sign of bad designs.

I remember on I was a team of a few developers. This was my first real programming job. (Instructional Systems department at my University). I was just starting to code some stuff, and the project leader insisted that for the particular task given to me, that I was NOT to use globals. I was not too far down the coding process, and thus I re-wrote the code to not use globules. Wow, what good decision that was. The results were MUCH better. The largest bonus is of course that the code can be pulled out, and used else where. Further, that “forcing” of me to make a better design was really one of those special times. I was learning from a good leader.

The other big issue is of course maintenance is far better when you don’t have to deal with globals.

Ok, now that the above is clear, there are number of good reasons to use globals.

    Sharing of large amounts of data can often be better accomplished by global data. Having direct access to a video memory buffer as global pool of memory is a good example. Today, we don’t access graphic memory that way anymore, but at one time this was common (pun intended).

Shared Constants that change.
A typical example of this was terminal definition codes. (you know, green screen stuff). Often, the keycodes in these types of applications was simply a global set of vars. This simply meant that all key codes for things like arrow keys etc was available everywhere in the application. However, the keycodes where set at load time based on the kind of terminal attached (Adds ViewPoint, VT-100, Wyse 50).

I mean, even today, the key code constants such a vbKeyEscape etc really are a global defined constants in VB. In a green screen environment, the value for vbKeyEscape was actually set at runtime. (in fact, for different flavors of pick, some systems returned 27 for esckey, and other returned 251 (if my memory serves me correct).

Hence, keycodes are needed everywhere. In products like vb, the keycodes don’t change, but that is not the case for all development environments. Thus, having a global set of vars for frequently used keys like arrows etc makes sense. Ditto the same for printer codes (again, something we don’t deal with anymore).

Environment Variables.
Again, one can argue that there is little difference between a global function, and a global var that returns a value. For sure most designs should wrap this stuff in a nice object, but that may not always be available.

In addition, Named “common” can also aid in the development process. Fortran anyone?

Hence, I am the first to state that don’t use globals. However, depending on the software platform, they are  a fact, and even a way of life.

So, lets not just hang those globals up at the ok corral and shoot them just yet.

Somewhere out there, someone right now is running my code that has a lot of globals…

Albert D. Kallal
Edmonton, Alberta Canada

Albert D. Kallal
Wednesday, January 29, 2003

Hehe, it's taken me a LONG time to get over the stigma of global/static variables and to accept them as a useful tool. The "holy grail" for some programmers seems to be one global variable:

Application *theapp;

but I've found many many situations where they are superior to the alternatives: command-line arguments, global configuration info, "context" pointers for long series of repeated operations, etc...

I should add that my definition of "global variable" includes things in thread-specific storage; e.g. "context" pointers need to be per-thread or chaos breaks loose.

Dan Maas
Wednesday, January 29, 2003

I can't remember the last time I used a global variable.

In the above example, I would declare a single private pointer to CApplication, create it somewhere convenient near the start of execution, and access it via a global function : CApplication * GetApp(). (In MFC the AfxGetApp() function does this for you for free). I don't consider this to be as bad, as you can call GetApp() again and again and again from anywhere without any side effects.

As mentioned above, I use this for performance reasons. For example, you have a container of objects, each one needs some common values, and the overhead of setting each one up to refer to the same object that provides these is too much of an overhead.

Better than being unemployed...
Wednesday, January 29, 2003

I've just been using lots of single purpose singletons that hold all of the necessary data for an individual piece of functionality.

Self-contained *and* predictable.

Wednesday, January 29, 2003

I am not against globals in any form (global var, global function returning an object), except for one:

  The Global Context Object

In my current assignment I see its reincarnation as CApplication. It wouldn't be bad if it weren't for the items collection attached to it.

Now all different kinds of objects reads, alter, deletes and stuff things into the pApp.items collection, then this object is passed around to all different methods throughout the application. This object is passed beyond both class and dll boundaries. Just trying to follow it causes great headaches.

What I think made this beast the worse of all is: We have no clue by looking at it what it may contain, and we don't know when wha'ts-ever-in-it will be used or by whom.

My goal is to get rid of it, but that require klocs of rewrites

Thomas Eyde
Thursday, January 30, 2003

One of the biggest design flaws in a project I've inherited is a library that has a global CApplication with public instances of CCurrentThis, CCurrentThat and CCurrentTheOther. Global-tastic.

Looks like it was written by a guy who didn't know how to call things by reference, too...

Better than being unemployed...
Thursday, January 30, 2003

From a relatively inexperience Window/Form developer I have a related question - how do I pass data from 1 form to the next without creating to what amounts to a global variable?  i.e.

I add a public WhatchamacallIt member to each form and pass it around like so:

GForm frmSomeDialog = new GForm();
frmSomeDialog.SomeDataMemberIWantToGetFromTheCurrentForm = this.DataMember;

Thursday, January 30, 2003

Hmm, not sure what language you're using (C#? Since you mentioned forms...) but the general way to do it is to write a pair of accessor functions. One to get the internal value, one to set it. Though don't write them if you don't need them - if you only never need to get the value, don't provide a function to set it. Then nobody will accidentally set it.

For example :

class CBar;

class CFoo
    CBar * m_pBar;
    CFoo() {m_pBar = new CBar;}
    ~CFoo() {delete m_pBar;}

    CBar * GetBar() {return m_pBar;}


Better than being unemployed...
Thursday, January 30, 2003

if you go multithreading, globals suck even worse...

Jutta Jordans
Thursday, January 30, 2003

We found a great way to remove globals from our C++ code. We made them classes and called them 'Singleton Patterns'. ;-)

David Clayworth
Tuesday, February 04, 2003

Interestingly enough, this month's C/C++ Users Journal has a column titled "Don’t let Singletons degenerate into global variables." It, obviously, explores the problem of Singletons being nothing more then a place to keep global variables for some people.

Tuesday, February 04, 2003

*  Recent Topics

*  Fog Creek Home