We're speaking at
CFUnited 2008:
CFUnited - The Premiere ColdFusion Technical Conference

Search

Calendar

SunMonTueWedThuFriSat
    123
45678910
11121314151617
18192021222324
25262728293031

Subscribe Enter your email address to subscribe to this blog. You'll receive an email when we write a new post.

Recent Entries Come On In, Rails-The Water's Warm
Shan's Simple Examples: File uploads with Flex and ColdFusion

Recent Comments Google Calendar API - Creating a new Calendar with ColdFusion
Steve Julian said: When and where are you going to post the finished CFC's ? Thanks [more]

Three Phases of Programmer Development
Pat Branley said: I normally think of those phase 2 people as 'programmers' and the phase 3 people as 'developers'. I... [more]

New Job Title: Front End Engineer
Sean Corfield said: Well, there's always the excellent Fusion Authority Quarterly Journal... [more]

Down To The Wire: HTTP Sniffers
Brian M said: I second the mention of the Charles Web Debugging Proxy that Tariq mentioned. It is fantastic. It s... [more]

New Job Title: Front End Engineer
Patrick said: Heya Sean. Good point. I never understood how they did things over there at SysCon, and I understand... [more]

Archives By Subject Business of Software (4) [RSS]
ColdFusion (318) [RSS]
Conferences (6) [RSS]
Databases (87) [RSS]
Flex & Flash (109) [RSS]
Fusebox (87) [RSS]
General Development (29) [RSS]
Google (9) [RSS]
Hardware (5) [RSS]
JVM & Java (132) [RSS]
Linux (20) [RSS]
Miscellaneous (254) [RSS]
Performance (8) [RSS]
SeeFusion (36) [RSS]
Shan's Simple Examples (7) [RSS]
User Interface (3) [RSS]
Windows (5) [RSS]

Archives By Poster Daryl Banttari (10)
Nat Papovich (29)
Patrick Quinn (36)
Shannon Hicks (22)
Steve Nelson (21)
Tyson Vanek (3)


bottom corner

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

Related Blog Entries

Comments
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
# Posted By Abdul Qabiz | 1/22/08 8:21 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.
# Posted By Steve Nelson | 1/22/08 8:37 AM
This is an interesting thread and I wonder what your collective thoughts are on frameworks that reside in the Application scope in ColdFusion?
# Posted By Mike Brunt | 1/23/08 8:25 PM
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.
# Posted By Steve Nelson | 1/24/08 7:28 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.
# Posted By Mike Brunt | 1/24/08 7:53 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.
# Posted By Steve Nelson | 1/24/08 9:10 AM

bottom corner