Calendar
| Sun | Mon | Tue | Wed | Thu | Fri | Sat |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | ||||
| 4 | 5 | 6 | 7 | 8 | 9 | 10 |
| 11 | 12 | 13 | 14 | 15 | 16 | 17 |
| 18 | 19 | 20 | 21 | 22 | 23 | 24 |
| 25 | 26 | 27 | 28 | 29 | 30 | 31 |
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)
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


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
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.
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.
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.