It's been about five years since I inscribed my "Ten Commandments of ColdFusion Development" for my first ColdFusion book, and as Commandments should, they've remained the same (more or less) with each subsequent revision.

Well, it had to happen. Unlike the other (and far more famous) Ten Commandments, mine were starting to stale and show signs of aging. So this month, in honor of the Second Annual Worldwide Allaire Developer Conference, I present to you "The New and Improved Ten Commandments of ColdFusion Development."

Nothing here is unique to CF development. These Commandments are just common sense, no matter what development you're doing. In addition, the Commandments are intended as starting points, not the final word. I strongly urge you to create a list (or adapt mine) of rules to govern your own development. Do so and be blessed with peace, prosperity...okay, I won't go there.

I: Plan Before You Code
We've all done it, and probably more than once. ColdFusion makes it so easy to start coding that often there's the temptation to start proj-ects by firing up ColdFusion Studio and creating CFM files. That's a bad thing indeed. Nothing is more harmful to your development efforts than failing to plan properly, and you should be spending more time planning than coding, not less. And I don't mean planning your IPO.

Planning involves thinking through every aspect of your application, from database design to UI considerations, from resource management to schedules and deliverables, and from feature lists with implementation details to language and presentation. You'd never build a house without detailed blueprints (you might try, but you'd never get the necessary permission to begin work); building an application is no different.

I'm constantly amazed by the number of applications I'm asked to look at that have no supporting documentation. And not just small development shops — I'm talking about some of the largest and most respected corporations. Scalability problems? I wouldn't doubt it. I'd actually be amazed if such an app ever did scale. You can't expect scalability from an application that grew in spite of its developers. Nor can you expect it to be bugfree, manageable or delivered on time.

Yes, I know that detailed planning takes time, time none of us have. But in the long run you'll come out ahead.

II: Organize Your Application
An extension of planning your application is organizing it (along with any other applications). Applications are made up of lots of little bits and pieces, and keeping them organized is imperative.

This includes directory structures and determining where common files should go, moving images to their own directory (or server), breaking long files into smaller, more manageable (and more reusable) ones and even ensuring consistent organization among different applications.

Going back to the prior Commandment, "Plan Before You Code," all organization should be documented in detail as part of that plan.

III: Set Coding Standards
This is an interesting one, and one I get asked about often. Allaire hasn't published formal recommendations on coding standards, nor in my opinion should they. Allaire's job is to create killer tools and products for us developers; our job is to use them in the way that works best for us. I don't believe a single set of coding standards would work for all developers, but I also don't believe any developer should be writing code that doesn't adhere to a standard - any standard.

Coding standards include everything from file and directory naming conventions to variable naming conventions, code organization and ordering within your source, error-handling, componentization and much more. For example, if all variables that contain dates begin with "dt", then references to a variable named "dt_orderDate" become self-explanatory.

The purpose of coding standards is to ensure some level of consistency in your code. Whether it's to allow other developers to understand and work with your code or simply so you'll know what the heck you did (and why) six months down the line, coding standards provide a mechanism to create code that describes and explains itself.

There's no right or wrong coding standard as long as it's used. The only thing wrong with coding standards is not using them.

(If any of you have coding standards that you've developed and are willing to share, please e-mail them to me. I'll try to compile them for a future column, and if I use yours I'll credit you.)

IV: Comment Your Code
This is an obvious one, but apparently few of us have the time to pay attention to the obvious. So I'll say it once again: all code must be commented. (For the record, I'd fire an employee on the spot for turning in code that's not commented, that's how serious an offense I believe this to be).

Every source code file needs a header listing a description, author info, creation date, chronological list of changes, any dependencies and assumptions, and any other relevant information. In addition, every conditional statement, every loop, every set of variable assignments, and every include or component reference, must be commented with a simple statement explaining what's being done, and why.

It's a pain, I know. But the next time you or anyone else has to work with the code, you'll appreciate the effort immeasurably. You might even be able to make code changes safely without breaking things in the process.

V: Never Make Changes on a Live Server
Another obvious one, or so you'd think. But any time I bring this up in front of a group of CF developers the grins, sheepish looks and knowing glances convince me there are transgressors in our midst.

All development and testing must occur on servers established for just that purpose. Yes, this means you'll need additional hardware, but the cost of a new box is nothing compared to the cost of bringing down your application because that little change wasn't as little as you expected.

Write your code, test it, debug it as needed, deploy it to a testing server, test it some more and some more, then finally deploy it to your live production server. And don't repeat this process too often. Instead of uploading slightly changed versions of your application every day, collect the changes, test them some more and deploy them monthly, weekly or whenever works best for you.

The key is that your production server is sacred. Don't touch it at all unless you have to...the less frequently the better. And never, ever, make changes on them, even minor ones.

VI: Functionality First, Then Features
Another obvious one, and a common beginner's mistake. Yes, writing fancy DHTML menu-generation code is far more fun than writing data-entry validation routines, but the latter is far more important to the success of your application. Concentrate on creating a complete working application, then pretty it up as needed.

This increases the chance that you'll finish on schedule for a change. The final result may not be as cool as you'd like, but there's something to be said for an application that actually works, even an uncool-looking one. Furthermore (as explained in the next Commandment), it's very difficult to debug logic problems when the code is cluttered with fancy formatting and features.

VII: Build and Test Incrementally
You'd be amazed (or maybe you wouldn't) by the number of e-mail messages I get asking me to help debug attached files - attached files with hundreds of lines of code, often more, and often multiple files, all needed to make the application work. My standard response to these messages is, "Yes, I'll help you debug your code, but first narrow it down to just the few lines in question."

What bothers me isn't being sent the messages and requests (I know I'm going to regret saying this, but I really don't mind those at all). What really bothers me is that core code was never tested in isolation. This goes back to the prior Commandment, "Functionality First, Then Features." The same is true for testing.

When you develop core components of your application, test them. Write little test routines, hard-code or smoke-and-mirror as necessary, but however you do it, do it. Obviously you'll have to test your complete application when done, and some problems won't come to light until then, but the more you can test code blocks in isolation, the better.

VIII: Never Reinvent the Wheel, and Plan Not To
I've written about this one extensively, especially in this column (see CFDJ, Vol. 2, issue 2, "Preserve Precious Resources - Recycle"). Write code with reuse in mind, and reuse code whenever possible. When designing your code, put the extra time in up front to make sure it's not hard-coded or highly task specific unless it absolutely has to be.

The benefits? Being able to reuse existing code will shorten your development time. You'll also stand a far greater chance of creating bugfree code when you use components that have already been used and tested. Plus, if you do make subsequent fixes and corrections, all code that uses the improved components benefits. Lots of benefits and no downside whatsoever. Should be a no-brainer.

IX: Use All the Tools at Your Disposal, Not Just ColdFusion
Another one I've written about before (see CFDJ, Vol. 1, issue 3, "Take Your Database Out of Retirement" and CFDJ, Vol. 2, issue 3, "When Not to Use ColdFusion"). Unlike the other Commandments, this one is more ColdFusion specific. CF applications aren't usually stand-alone entities. They rely on database server, mail servers and much more. In addition, ColdFusion can leverage COM, CORBA, C/C++ code, and all sorts of Java- based bits and pieces. Use these tools, as many as needed, and always attempt to pick the best one for a specific job. The best CF applications aren't the ones written purely in ColdFusion; they're the ones that leverage the best technologies for the job, all held together by ColdFusion.

X: Implement Version Control and Source Code Tracking
Source code changes. And changes are dangerous. As your applications grow, so does the need for tracking changes and source code control. Pick a version control package that works for you, and use it. Key features to look for are:

• The ability to lock files (so no one else edits a file while you edit it; if that happens someone's changes will be lost)
• The ability to view change history (what changed, by whom, when)
• The ability to roll back complete applications (so when the latest upgrade bombs you can easily roll back an entire application to a prior known state)
• The ability to create and check file dependencies (so you'll know what other code is affected by changes you make)
• Reporting

Summary
There you have it - my new and greatly improved "Ten Commandments of ColdFusion Development ." Movie rights haven't been sold yet, and the lead role hasn't been cast (the obvious choice is busy with the NRA right now). If any progress is made in that department I'll let you know. In the meantime, good luck with your coding, and I look forward to meeting you in November at the Developer Conference in Washington, DC.

• Figure 1