Just as in Rookie Mistakes Part 1, this post will cover mistakes that we've all made at one point or another. These are things that seasoned developers instinctively know to do, but beginners may not realize are better or more efficient. Some of this post is based loosely on Adobe's Coding Best Practices for ColdFusion Performance, with a few of my own personal favorites thrown in there.

1) Application Multiplication

NOTE: This section is a rewrite of my original "Application Multiplication" section. My original post seemed to have some misinformation in. (see comments below) Actually, it wasn't misinformation...what I originally posted was flat out wrong. Actually, it wasn't just flat out wrong...what I originally posted was the exact opposite of how Applicaiton.cfm really works! Thanks go to David Boyer and Larry Lyons for straightening me out! And, yes, I do feel stupid. Thank you for asking. ;^)

One thing that those new to CFML sometimes don't realize is that the Application.cfm file is run on every .cfm page request, before any other CFML code gets executed. The same thing applies to OnRequestEnd.cfm. Application.cfm only gets called once per request, so if you have an index.cfm page that has 2 cfincludes (both including a .cfm page) inside of it, Application.cfm still only gets called once. This is important to note because I originally thought that Application.cfm got called once for every .cfm page (including the includes) instead of once per request. But, as it turns out, that is not the case (see http://help.adobe.com/en_US/ColdFusion/9.0/Developing/WSc3ff6d0ea77859461172e0811cbec22c24-7d6f.html).

Since Application.cfm gets called every time you make a request to a .cfm page, that means any variables that are getting set in Application.cfm, and any queries that are being run in Applicaiton.cfm, and any other code in your Application.cfm file is being run over and over again unless you have some conditional logic preventing it.

For example, let's say we're setting our datasource to an application variable in our Application.cfm file:

This code pretty much defeats the purpose of an application variable. It is constantly resetting the application variable, whereas you generally just want to set an application variable once and leave it alone unless it changes. If you're going to reset the variable every time a .cfm page is called, there's really not much point in putting it in the application scope.

The proper way to do this is:

Now we're telling Application.cfm not to bother setting our variable unless it doesn't exist. So, Application.cfm will set the variable once, when your application first starts, and not worry about it any more. It's also important to remember to use cflock whenever you're writing to a shared scope (such as application or session).

As a side note, Application.cfc came out in 2005 with ColdFusion MX 7 as a replacement of the traditional Application.cfm and OnRequestEnd.cfm application templates. Application.cfc gives you much more detailed control over how and when things are called than Application.cfm does. If you're not yet using Application.cfc instead of Application.cfm, I would highly recommend that you try to do so if at all possible.

2) Fun with Nested Functions

Another thing that CFML newcomers may not realize is that you can nest functions together. So, instead of having multiple cfset statements, you can combine your functions into one statement.

For example, instead of:

You could have:

This works great when you don't have many functions. However the more functions you nest together, the more convoluted it gets. Take the following example:

If you tried to nest these together into one cfset statement, you would have:

While this would work fine as far as processing the code goes, it's getting a little jumbled up and hard to read. When it comes to using nested functions, there's really no "best practices" rule that I know of. It can go either way. They're fine if you just have a few of them together, but it's probably better to break them up if you're going to have several of them. There's not really much of a performance hit either way, so it really just comes down to how readable you want your code to be, and how much you like to type as to whether or not you use them.

3) You'd better be Query Paramin'!

Always, always, always use cfqueryparam. There is no valid reason not to (ok, there are 1 or 2 valid reasons, but they are rare!). If you don't currently use cfqueryparam stop what you're doing right now, go to the nearest whiteboard and write this 100 times: "I will always, always, always use cfqueryparam because it's the right thing to do, and I am not a slacker. I love my applications and want to code them in a way that will not make other CFML coders point and laugh at me. I will always, always, always use cfqueryparam." Go ahead, I'll wait.

Seriously, though, cfqueryparam is so very important and should be used at all times. It's not hard to use and it has several benefits, such as increased performance and added security against SQL injection attacks. One of my favorite features of cfqueryparam is its ability to handle dates. That's actually what got me started using cfqueryparam several years ago. I was working on an Intranet app that was connecting to both SQL Server and Oracle databases. I was always having to format my dates with createOBDCdate() or to_date() until I found out that cfqueryparam handles that for you. So now all I have to do is put my date variables in a cfqueryparam tag and it takes care of the rest.

I'm not going to get into all of the details of cfqueryparam and how to use it. Here are a couple of good (old) articles that already do that. I'm just going to say that if you don't use it, the day will come when you regret it. For me, that time was at the office at 10:30 one night after I'd spent all day trying to recover from a malicious attack. My boss at my first IT job once told me "It's not a matter of 'if' you get attacked, but 'when'". Turns out, 8 years later, he was right. So always, always, always use cfqueryparam. (I mean, come on...it came out with ColdFusion 4 in the '90s! Get with the program!)

This post is part of a continuing series of CFML 101 articles. My intent is to produce a blog series aimed at the beginning CFML developer, one which helps to explain basic techniques and concepts to those new to the CF world. The topics and examples covered in this series focus on the CFML programming language in general, not a specific application server. So whether you're using ColdFusion, Railo, or Blue Dragon (referred to as CF/R/BD) to run your CFML applications, these concepts still apply.