Someone recently asked me about the difference between using Evaluate() vs. using array notation to get a dynamically-named query column value. I argued for using array notation. On one hand, I believe that it is minutely faster; but, the bigger issue is that using array notation is a more assertive coding style. After responding to that, I kind of wanted to get this off my chest.
NOTE: The following is just my opinion, it's not personal.
Coding style is important. And I'm not talking about readability and maintainability (although those are huge factors). Your coding style says a lot about you and your understanding of the features of a language. To me, use of non-assertive code such as ColdFusion's Evaluate() and IsDefined() methods, subliminally tell me that you don't know how to properly param, reference, or scope variables. These are weak, code-by-coincidence statements and I think they reflect poorly upon the coder.
Just as with the English language, using a more assertive style makes you seem like a more confident and knowledgeable programmer. For a second, take a moment to think about a non-programming environment. Think about working out in the gym with a training partner. In my experience, there are two types of training partners: assertive and non-assertive. Let's say you're getting ready to do a set of bench press. Here's what a non-assertive partner might say:
"All right, let's see how many you got!"
Now, let's compare that to what an assertive training partner might say:
"Let's go big man! You ain't getting off this bench till you give me 8 fucking reps!"
Which one of these training partners do you think is going to motivate you more? Which one is gonna help you push yourself hard to make gains and continual progress? This isn't really a subjective question; the non-assertive partner doesn't provide a reachable task. "See how many you got" does not provide a structured environment with tangible goals. On the other hand, "Give me 8 fucking reps!" is a highly tangible, black-and-white task that is within reach (if for no other reason than the fact that it can be distinctly measured).
Now, jumping back to programming, the same principles apply. Let's say you code something non-assertively like:
IsDefined( "form.first_name" )
To personify it, that's akin to being like, "Excuse me, has anyone seen my variable, form.first_name? Hello? Is anyone listening to me? First_name? Anyone seen it? No? Yes? Is it over there? First_name - starts with 'form'?" This is a really weak style and it comes across as being unsure about how the code is supposed to function.
On the other hand, if you code something assertively like:
StructKeyExists( FORM, "first_name" )
To personify it, that's like saying, "First_name, you better be in the FORM scope, otherwise some shit's gonna go down!" This is a much stronger statement and demonstrates that:
- You know where your variable is supposed to be.
- You know how structures work.
- You understand scoping mechanisms.
- You understand the difference between a "variable name" and a scoped variable.
Think about this code for a second:
<!--- Set variable. ---> <cfset VARIABLES[ "form.how_sexy" ] = "Too Sexy" /> <!--- Check variable existence. ---> #IsDefined( "form.how_sexy" )#
Do you have any doubt as to what this will return? Any doubt at all? A shadow of a doubt? I know that I did. I've been coding ColdFusion for 8 years and I just ran a test to see what the above code would do because I wasn't sure. And why was I not sure? Ignorance? Matter of fact, yes. But also, this code is potentially ambiguous. The VARIABLES scope should be searched before the FORM scope, so it could be argued that ColdFusion should have looked in the VARIABLES scope for the named variable before it looked in the FORM scope.
But really, the point here is not so much that I should have known how the code worked and more so that the code was not assertive. Had the code been the stronger statement:
#StructKeyExists( FORM, "how_sexy" )#
I would have had no doubt as to what it was trying to accomplish.
Ok, time to stop ranting and start billing clients. But just remember, assertive coding is better. Now, that's not to say that there are no use cases for Evaluate(), there are; I am just saying that in the cases where it is not required, it would reflect more favorably upon you NOT to use it. As far as IsDefined() - I am not sure I have ever seen a situation where this could not be replaced with more assertive code.
Want to use code from this post? Check out the license.