Ben Nadel
On User Experience (UX) Design, JavaScript, ColdFusion, Node.js, Life, and Love.
I am the chief technical officer at InVision App, Inc - a prototyping and collaboration platform for designers, built by designers. I also rock out in JavaScript and ColdFusion 24x7.
Meanwhile on Twitter
Loading latest tweet...
Ben Nadel at the New York ColdFusion User Group (Dec. 2008) with: Clark Valberg

Spacious Formatting For Inline ColdFusion Variable Evaluation

By Ben Nadel on
Tags: ColdFusion

I was just reading Elliott Sprehn's test cases for Ray Camden's Friday Puzzler when I came across something very interesting: at the end of his file, he has his hash signs (#) and his variables on different lines for inline evaluation. I have never seen this before, so naturally I had to test it:

  • <!--- Set up girl object. --->
  • <cfset objGirl = StructNew() />
  • <cfset objGirl.Hair = "Brunette" />
  • <cfset objGirl.Cuteness = 9.5 />
  • <cfset objGirl.Hotness = 7.5 />
  • <cfset objGirl.Athletic = false />
  • <cfset objGirl.Curvey = true />
  •  
  •  
  • <!---
  • Determine general "hotness". This may or may
  • not correlate to the hotness factor.
  • --->
  • Girl Is Hot:
  •  
  • #
  • ListFind( "Brunette,Black", objGirl.Hair ) AND
  • (
  • (
  • objGirl.Athletic AND
  • (objGirl.Hotness GTE 8.5)
  • )
  • OR
  • (
  • objGirl.Curvey AND
  • objGirl.Cuteness GTE 8
  • )
  • )
  • #

Running that (to make sure we don't get any ColdFusion errors), we get:

Girl Is Hot: YES

Notice how spaced out the code is? I am not saying that I would necessarily do it this way, but I have variable evaluations that are very long and highly unreadable. It is nice to know that I can make things a bit more readable by breaking it up by lines. I am just shocked that the hash signs don't have to be directly next to either a variable or an expression. Very cool.

Remember people, 80% of the cost of a project goes into maintenance... make your code readable!



Reader Comments

I don't find that very readable at all. Im sure ever situation is different and you are forced to write code like that sometimes, but if it starts getting unreadable, and especially if you are having to do the same code more than once, why not pull the logic out into a udf? even if its on the same page, it would be a ton more readable than that.

Reply to this Comment

@Ryan,

I agree, so far as pulling repeated code out into a UDF. Yes, there is a rare case where something like this would need to be done. And, while you might not find this readable, I am sure it is more readable than having that all on one line.

Reply to this Comment

Yeah it works, for the same reason you can do that kind of thing inside a <cfset> statement.

ColdFusion defines the cfset statement as:

<cfset ((Identifier|String) =)? expression>

Where the left hand side of the statement is optional, and the right hand side is an expression that evaluates to some value. Whitespace between any of the parts is valid, CF doesn't care if there's new lines or spaces before, or after the Identifier/String, expression or assignment operator.

The pound syntax in CF, which can be defined as #expression#, is just the right hand side of the cfset statement. We know this because CF forbids placing the left hand side of the statement inside pound signs. (ex. #foo = 1# is a compiler error).

Thus we can reason that whatever is allowed on the right hand side of a cfset is also allowed inside pound signs.

This has some curious implications as far as syntax goes because you can do something like:

<cfloop collection="#

server

#" item="name">
<cfoutput>#name#</cfoutput>
</cfloop>

We can also reason that:

"2sheep" EQ "#

1
+
1

#sheep"

And all kinds of other fun syntactic craziness. I'd not say this kind of thing is best practice for most cases, but it illustrates what CF sees when you use expressions.

Reply to this Comment

Post A Comment

You — Get Out Of My Dreams, Get Into My Comments
Live in the Now
Oops!
Comment Etiquette: Please do not post spam. Please keep the comments on-topic. Please do not post unrelated questions or large chunks of code. And, above all, please be nice to each other - we're trying to have a good conversation here.