A New Reason to Not use Global Variables
It’s been 10 years since I first heard someone say that global variables are bad news.
To be truthful I didn’t really understand the reason back then. The most common reason not to use global variables is the namespace argument. Basically the problem is that you can accidentally overwrite another variable. Yeah ok, I guess that’s a problem, but it so rarely affects me I don’t think about it much.
But who can argue with computer scientists? Not me that’s for sure. Whenever I try, I end up feeling stupid.
Well, I have a new reason not to use global variables: Unit testing. Unit testing affects me every day.
Don’t get me wrong, you can use global variables when unit testing, of course you can. The issue is that when you introduce global variables you suddenly break the rules of unit testing, which is to test small portions of the codebase on its own. Global variables mean you need to test multiple units together. This complicates the testing process, something we do not need.
That’s two reasons not to use them, which is enough for me. Now how to break the habit? Cold turkey? The patch?
-Steve Nelson

As you mentioned, it’s not good idea to pollute global namespace. It might cause problem in garbage-collection also, if you use global variables to refer to object, you have to keep track of all such variables and set the reference to null..
Whether it’s JavaScript/ActionScript, both use ReferenceCount method along with mark-and-sweep (used in browser-dom)…
Having your own namespace also creates global var, but just one which you can control…
-abdul
Comment by Abdul Qabiz — January 22, 2008 @ 12:00 am
Yeah, the namespace argument is pretty weak, like you said you can just make a top level variable.
But that’s not why I dislike global variables. I’m suggesting a new reason for not using global variables, unit testing. It’s a bigger problem IMO than the namespace issue.
Comment by Steve Nelson — January 22, 2008 @ 12:00 am
This is an interesting thread and I wonder what your collective thoughts are on frameworks that reside in the Application scope in ColdFusion?
Comment by Mike Brunt — January 23, 2008 @ 12:00 am
Well I’ve come to the conclusion that frameworks have become so utterly complex that they no longer provide a reasonable return on investment. My initial reason for Fusebox was to make it so new developers could easily jump into a project. Now that almost all frameworks follow the advice of computer scientists, you have to hold a doctorate in CS to easily jump into a project. IMO that’s bad. No, it’s atrocious.
CFCs have been a boon to frameworks, but they are SO powerful that at the same time they have made it easy to complicate a codebase. This quickly becomes counter productive.
Who knows? Not me.
Comment by Steve Nelson — January 24, 2008 @ 12:00 am
Steve if anyone can speak with authority on this it is you and I agree with you 100% we have gone off at a terrible tangent regarding frameworks. I have spent the past 7-8 years troubleshooting CF and JRun apps. Having a convoluted framework (which most now are) makes pinning down source problems near impossible and to be really heretical here; cfc’s extending cfc’s extending cfc’s is really nothing much different to multi-layered cfinludes in my opinion.
Comment by Mike Brunt — January 24, 2008 @ 12:00 am
I agree Mike. Extending CFCs is one of the big reasons code becomes hard to follow. It quickly becomes confusing as to where the code is.
The second thing I think makes code hard to follow is not knowing where a variable was set. That’s why I’ve become focused on passing EVERY variable into a method through an argument. It seems obvious, but so often it isn’t done. Variables come in from request and session scopes, then you have to hunt down how that works.
The third thing that makes code hard to follow are scattered directory structures. Frameworks tend to ease this pain a bit.
The fourth thing is caching. Jebus does caching ever make debugging a PITA unless you wrote the code to begin with! Caching is often an unfortunate reality.
I can come up with another few dozen things. I’m sure one of these days I will.
Comment by Steve Nelson — January 24, 2008 @ 12:00 am