CFM Coding Standards
CFM Best Practices
Coding Standards are extremely important in all our projects, To help, I've gathered a concise list of Coldfusion coding standards to keep developers effective and productive.
Date : 2009-04-14
ColdFusion Coding Standards
ColdFusion is a powerful programming language that has a different structure from most other web development languages. Because of that it really requires a different set of coding standards. It's possible to reuse patterns between PHP and ASP, but those same patterns will rarely port to CFM.
The basic parts of this coding standard are:
Starting with Naming Guidelines here are a few things that all ColdFusion programmers should know when naming entities. ColdFusion is definitely a language that aims for human readability. This being the case names should be chosen for readability. Abbreviations should be avoided unless they are well known and obvious in their usage. A general rule to remember is that the primary role of an entity should be obvious from it's name. “verb-noun” and “adjective-noun” are common patterns. Beyond that a difference could be seen in files, components, and variables, functions, attributes, properties.
Name as follows:
Pages : list_customers.cfm in underscored in verb-noun format.
Components : CustomerReview.cfm in initial upper Camel Case.
Variables : customerName, customerEmail in initial lower Camel Case.
Database table names should be singular (customer_order NOT customers_order, or customer_orders)
Databsae fields should not include the table name unless it's necessary to understand the purpose of the field. An example when that could be the case is almost every table would have an ID field, which might better be named ORDER_ID, and PRODUCT_ID.
Moving on to Site Structure there are a few necessary items.
application.cfm – application wide settings and processing. Error handling is sometimes setup in here
components/ .cfc files
customtags/ .cfm custom tags
includes/ .cfm include files
/config .cfm configuration files
When referencing files in the site structure don't use full domain names unless absolutely necessary, for instance when switching between insecure and secure pages (http:// to https://) This allows for multiple domains used for development and live servers/domains. This is a good practice for any language. Another step you can take to avoid issues even when switching from insecure to secure is to store the domain name in the config files. Your development server can have a secure URL if necessary or can just be blank to stay on the same server while your live server references the live secure site.
Now lets focus on some best practices that can make your code better. Some of these are applicable to any development language and some are specific to CFM.
First, use whenever you have 3 or more logical If's to handle. Although a and exist you should never really have to use the . should be used only in a if/else situation.
When calling components use the tag to pass arguments to the component. This allows for type checking and other validation.
When testing booleans don't test against “true” or “false”, although that works you should use:
Another thing to keep in mind working with CFM, because the page code is in a tag structure similar to HTML it is important to be very careful with your tags. While Coldfusion doesn't require single tag commands to be self closing:
(this is perfectly fine in CFM)
It is still a good practice to self close single HTML tags:
(the standard example)
That being said, it is a good idea to use self closing CFM tags as they wont break and could have the affect of helping keep both tag structures more consistent. SO, try getting in the habit of using:
Some of these coding standards are fairly obvious but we state them so that everyone can be on the same page. Many of these Coding Standards are found on Abobe's site at: Adobe Coding Standards
No comments yet