ColdFusion Pet Peeves
In the recent spirit of posting top 10 lists, I thought I’d throw in my 10 ColdFusion related pet peeves. These aren’t peeves about the language itself though, but peeves in how people code. We all know there is no “right” way to make an application, so all of these are up for debate, but that doesn’t mean they’ll stop annoying me.
- Cased tags. Why some people insist on putting CF tags in all caps I’m not sure I understand. It could be to differentiate them from regular HTML, but if that’s become a problem then you’re probably mixing logic or unfamilar with HTML. To me it just looks like the tags are shouting.
- Cased functions. Not all case is bad. I prefer using the official case found in the CF docs for ColdFusion functions. Having these in all lowercase makes them harder to read, and all uppercase gives the same problem as the first one.
- Uppercase scopes. Scopes shouldn’t be yelling either! variables, application, url — looks better to me than VARIABLES, APPLICATION, URL.
- Not returning this in CFCs. This isn’t a clear cut rule of course, but for most day to day applications working with object makes things a lot easier. In my first experiences with CFCs this wasn’t the most obvious way to do things, so I can see why some people might have not have learned a other ways, but this will help.
- Using the this scope. This one has almost been cleared out of common practice, but using the this scope in CFCs for variables isn’t the best idea. When you store a variable in the this scope it will be available from outside the object. This breaks encapsulation, and also makes for ugly code.
- Forgetting output=”false”. This could be a CF pet peeve as well, but assuming CF doesn’t change we’ll need to continue adding output=”false” to all methods we don’t want output to the browser. Usually this is just about all methods too. It seems redundant but it’s helpful, and nice not seeing a whole lot of blank space at the top of your pages.
- Not using var scope in CFCs. Within functions, you need to localize your variables by prefixing them with var, as in
<cfset var qry = "" />. This will keep that variable within the function. Not doing this might not seem like a big deal, but there are two notable side effects. For one, if this object is persisted, so will any saved values. Also if this object is persisted, say in the application, then run by multiple pages, they might overwrite each others variables if they’re not defined with the var prefix. Some things like querys and query generated variables also need to be var scoped. - No trailing slash This is a big one for me actually. In order for CF to look more like a valid language it’s important to close trailing slashes.
- New mappings needed. It seems like just about any application you download needs to have a mapping added for it. Although in CF8 there are ways of doing this within the code, it’d still be nice if there was a more universal standard for naming packages so that less mappings were needed. Imagine having a “com” and an “org” mapping and all frameworks were pretty much in those? I’m probably oversimplifying the solution, but it’s an idea. In the meantime it is possible to add a base directory to the cf tags directory then throw all your frameworks in there. From what I’ve seen, this works with most frameworks such as ColdSpring and Fusebox, although it doesn’t work with Reactor since it stores it’s created CFCs within the /reactor mapping.
- Reinventing the Wheel. You knew it was coming. Creating an in house framework sounds great, but building off something that’s already there usually makes more sense. I was originally thinking “CFC heavy sites that don’t use ColdSpring” for this one, but any under use of a framework could apply.
Any big pet peeves of yours that I’ve missed?
‘doesn’t work with Reactor since it stores it’s created CFCs within the /reactor mapping’
This is not completely accurate. While Reactor does store generated files within the /reactor mapping, these files should not be altered. The files that are created that you can use to override native reactor methods, or create custom methods are stored under the project in which you are using Reactor.
@Scott
True, the /reactor mapping stored files should never be altered. It does, however, mean you need a /reactor mapping for it to work, rather than adding it to a global lib. Not a big pet peeve when you only have to map one framework, and not meant to single out Reactor, which is a great framework.
Big pet peeve of mine: Wrapping an entire file in a cfoutput tag. This causes huge whitespace chunks in the html source and also causes a performance hit (however slight or large) from the parser having to parse all the text in the cfoutput tag.
My pet peeves happen to be disagreements with two style practices that are told to people as required:
1. The This scope has its uses and people saying to never use it are wrong. Better to explain the whole issue with it, where it can and even should be used and let people come to an educated and informed decision. Absolutes insult peoples intelligence.
2. Ending slashes in tags are totally a style issue with no real usage other than how the code looks. Any statement of “CF to look more like a valid language” or “We need trailing slashes to be standardized” runs into a single problem: cfif. ColdFusion is not XML, it is not PHP and it is not Java. Why do we have to compare ourselves to something else for validation. We came first in many cases and other languages have followed us (tag based paradigm).
But these are my pet peeves and are not anything against you personally.
@Bucky
Yeah, that’s a good one. It’s insane how much that can affect performance too.
@Michael
Good comments. I rarely see good uses for the this scope, but to discount it completely wouldn’t be a good idea either. I was leaning towards using the this scope to set/get variables mostly. I haven’t seen a good argument for using it in that case so perhaps that’s more clearcut. It’s still a powerful scope though, so I’m sure there’s a lot to it I’m not addressing.
Ending tags for me means being able to see where that tag ends more than anything else. In other languages you have opening and closing braces, but in coldfusion i prefer to use valid xml to represent opening and closing braces. I’m sure most people familiar with CF have no trouble seeing what’s a multiline tag and what’s a one line tag, but for uniformity and readability it still makes things easier to me. Good point about cfif though; even at it’s best it wouldn’t be valid XML.
i’m a bit late to the party, but
is not valid xml either…
ugh..
<cfset foo = true />
why people have technical/developer blogs that strip code samples out of their comments is MY biggest pet peeve…
Regarding trailing slashes: I have to say I am against trailing slashes in CFTags which don’t have a closing tag. For one thing, whilst the code executes normally with the built in tags, guess what happens when you try to stick a trailing slash at the end of a call to a custom tag which doesn’t usually have a separate closing tag? It executes twice!
Yeah, custom tags are crazy like that. I’ve usually liked the practice of exiting out of the customtag depending on the executionMode, so that way it’s guaranteed to only execute once (or however many times you’d want it to) regardless of how it was implemented.