Between Ben Nadel's blog and my blog, there has been some discussion on the use of CFLock, and a lot of the comments and questions are related to what we as a community consider "Best Practices".

Most ColdFusion developers consider it "Best Practice" to always lock the application scope every time you use it in your code. A lot of this really stems from the early versions of ColdFusion, when not locking your application scope could cause memory corruption. As of CF MX memory corruption is no longer an issue but race conditions are still possible, so Adobe still recommends that you lock your application variables as a "Best Practice" to be on the safe side.

Unfortunately, many developers really don't understand CFLock, and many developers don't understand that "Best Practices" are not always black and white.

While some best practices should be adhered to rigidly, others should be viewed more as loose guidelines. I try to follow "Best Practices" in most situations, but not at the expense of my application. If I know there is no need for me to lock a particular application variable, because it is never going to change once it is set and a race condition will never occur, then why bother with adding more processing to my server by using CFLock?

I want to be clear that I'm not against "Best Practices". On the contrary, I consider them essential to the entry level developer. It gives them guidelines that, when followed, will help them not to make as many inexperienced mistakes. Following "Best Practices" results in better code from a developer, regardless of their experience. All I am saying is that eventually a developer advances his understanding of what's going on behind the scenes, and begins to grasp not just that they should or should not program something a certain way, but why they should or should not program it that way. When the programmer is at that level, he is then ready to make determinations as to which "Best Practices" he should follow every time with "black and white" certainty, and which "Best Practices" have a bit of a gray area, where the developer has to determine what is better for his particular application.

A less experienced developer will be more apt to blindly follow all the "Best Practices" simply because they don't really understand what could go wrong if they didn't and that healthy fear of the unknown should cause them to err on the side of caution. A more experienced developer will be able to understand what the risks are, and make decisions to not follow the "Best Practice" when following the "Best Practice" will hinder rather than help their applications.

Related Blog Entries

Comments (Comment Moderation is enabled. Your comment will not appear until approved.)
Ben Nadel's Gravatar Well said. It's like the Matrix concept of "There is no spoon". It's like, once you truly understand the rules, what you really understand is that they're really are no hard-fast rules. But, that being said, following them until you understand, is a good thing.
# Posted By Ben Nadel | 1/16/08 4:09 PM
Tony Garcia's Gravatar As one of the people who brought up the whole "best practices" issue over on Ben's blog, thanks for the clarification. I agree 100%. I guess I'm at that transition point between newbie and "more experienced" developer where I'm really trying to be more mindful about "best practices" and not just apply them blindly, and learning from guys like you and Ben is invaluable.
# Posted By Tony Garcia | 1/17/08 4:24 PM
Ifeanyi Isitor's Gravatar It's the QUESTION that drives us Neo....

"... not just that they should or should not program something a certain way, but WHYYYY they should or should not program it that way".
# Posted By Ifeanyi Isitor | 4/13/12 4:44 AM