CFML Coding Guidelines

CFML Coding Guidelines

Posted by Luis Majano
Oct 27, 2013 21:42:00 UTC

I just wanted to share the Ortus coding guidelines with the rest of the community.  We have updated our coding guidelines document in our wiki:  This includes several CFML and ColdBox guidelines to help with projects.  Would love any feedback.

Update: October 30, 2013

Thanks to the comments below we have added a ColdFusion Builder formatter.  Just go to Eclipse Preferences > ColdFusion > Profiles > Formatter and click on the Import button.  You can download our formatter form here:


Andy K

you should put these into a file so that they can be imported into CF Builder's "Formatter". I'm currently using the Express version so I wouldn't be able to use it, but others would.

Andrew Scott

Can the documentation be fixed to include these changes, at the moment I see things like this that looks wrong.

Type Names All ColdFusion type names in arguments, return types and the like should all be in lower case when they are native ColdFusion types. If they are components they should be the EXACT name of the component. This is extermely important if for some reason the code executes in a case-sensitive system, then the code will not work. ALWAYS have the exact case of components and definitions. If no type is defined, then it is assumed it is uses the any type.

-- DO THIS -- <cfargument name="paths" type="array" > <cfargument name="user" type="model.users.User"> <cffunction name="getSecurityService" returntype="">

-- NOT THIS -- <CFARGUMENT name="paths" type="ARRAY" > <cfargument NAME="user" type="model.users.user"> <cffunction name="getSecurityService" returnType="">

I would like to see that fixed the right way round, as well as adding the guides to it would mean it should like like

<cffunction name="getSecurityService" returntype=""> <cfargument name="paths" type="array" /> <cfargument name="user" type="model.users.User" />

I notice all examples don't follow the guides with spacing either, I know its knit picking, but needs to be fixed up to show that in the documentation as examples. So as to not confuse the readers of the documentation.

Andrew Scott

Also when defining blocks of code you have this in your documentation.. However I always, and will never change when it comes to spaces before the opening curly brace for code blocks and you have it has a NOT THIS...

One other thing, I prefer all my arguments on the one line and not over 5 - n'th line. It is all about reducing the lines and making it easy to read. I applied your formatting to one of my files and changed it back right away. It looks ugly, makes the card far to hard to read... In my opinion.

// DO THIS component{

} try{

} if( false ){

} else if( XX ){

} else {


// NOT THIS component {

} try {

} try {

} if( ) {

} if() {

} else{


Site Updates

Entry Comments


Entries Search