Descriptive Variable Names

So the past week I've been working on porting Ray Camden's Galleon Forums application to several popular frameworks. There are some things I like about Galleon and then there are some things I wish Ray had done differently. Specifically one of the things I don't care for is that the factory that manages the business objects for Galleon is stored in the variable "application.objectFactory" and the settings are stored in "application.settings". In my mind, these variable names are just asking for trouble. I suppose if you made the assumption that your application would be a stand-alone application it might be okay, particularly for very specific corporate internal applications (although often enough, those have ended up becoming commercial products in the long run).

Though Galleon isn't the sort of application I would assume is "stand alone". Rather, I would actually assume the opposite, that any given forum application is very likely to be integrated with a wider extranet or possibly social networking application.

I would much rather have seen Ray's code specify something like "application.GalleonFactory" or "Application.Galleon" or maybe even "Application.Galleon.Factory". The latter is the way onTap framework variables have been declared dating all the way back to ColdFusion version 5, before CFCs were even on the drawing board. I've ended up with several sets of onTap variables and all of them in their respective scopes end up being "[scope].tap.whatever", so the file utilities are "Server.tap.FileMan" and I think the SQLAgentLocator service is "Application.tap.SQLAgentLocator" although it might be "request.tap.SQLAgentLocator". The advantage of course is that there's only the risk one variable collision, rather than risking many.

For example, if I had declared all my request variables as "request.SQLAgentLocator" and "request.ObjectFactory" those might each individually collide with a variable someone else declared. But by isolating my variables into the "tap" structure, the only namespace collision that's really likely to happen is with "request.tap" rather than with both "request.SQLAgentLocator" and "request.ObjectFactory" independently. Of course, the reason why Ray and I and many others harp on using the var keyword is because of namespace collisions between common "temp" variables like "x" or "i". If you've got a bunch of functions with loops in them, the chances are more than one of them uses "x" or "i" internally and if you nest those functions then BLAM namespace collision. That's also one of the advantages of Objects or OO programming (CFCs to us great unwashed heathens of the CF world), because nondescript variable names are much safer when they're properties of a highly cohesive object (similar to my use of the "tap" structure).

Even now, the onTap framework several years after the release of ColdFusion MX still likely exposes more of its internal variables than it really needs to, primarily because they're holdovers from CF5 before the advent of objects in ColdFusion. And yet, the risk of namespace collision with the framework's internals is in a worst-case scenario rather unlikely, merely because I sequestered them away into those "tap" structures.

Once, a number of years ago, I think actually before the release of ColdFusion MX someone asked me about the onTap framework "how do you avoid namespace collisions"? At the time this was in the manner of "why should I bother listening to your unconventional ideas?" I wish I had been more eloquent at the time. If I had, I might have replied "how do you avoid namespace collisions?" Because honestly, if you're giving your variables descriptive names, then even within a singular scope (the variables scope for example), namespace collisions should be something that might happen every thirteenth fortnight or so only on days when the wind is in the west, the vernal equinox is approaching and there are dark clouds on the horizon. In other words, if you're giving your variables descriptive names like you should, then namespace collissions should be pretty near the bottom of your list of things that are likely to go wrong.

Though I was a bit surprised to see Ray's choice of variable names, and it makes me wonder if perhaps nondescript variable names are more common than I think they are. And perhaps as a result, maybe so are namespace collisions.