This article will focus on practical ideas and habits that, when consistently applied, will allow you to develop and create better ColdFusion Applications – regardless of which CF version you use, the hardware you run on, or the methodology you employ – as well as make your development easier.
-> Know the Database
Many ColdFusion developers do not take advantage of the power and features of their database, often trying to solve problems in ColdFusion that are better solved through the use of SQL and or specific features in their database.
The main reason for this is that many CF developers feel the need for more than an understanding of SQL syntax and basic relational database theory. As a CF developer you need to understand that each RDBMS has specific strengths and weaknesses, and powerful tools and features that can make your life easier and your application more scalable and robust. The database may also have features that, if not understood, can make development more difficult.
Make sure you have read up on your particular DB and are at least aware of what it can do for your application. For example, many developers try to port code developed for MS SQL to Oracle, and find their join statements throw exceptions, never realizing that while their SQL is correct in the generic sense, Oracle does not support the Join statement and requires you to use the symbolic representation for a join rather than the literal statement.
When building applications, try to build your data model and data access routines independently of your application code. In Web application projects, it can be impractical to totally abstract the data layer from your code, but even in smaller projects you can write many of your queries independently of your ColdFusion code and use literals in the place of variables. In larger applications, and depending on your architecture, creating CFCs, CF custom tags, or templates that you later include into other code that contains your data access and manipulation code, makes a lot of sense. It allows you to test your SQL, reducing the amount of redundant code written, and increasing code reuse. Finally, it also allows you to use database tools to help analyze your SQL to increase performance and find bottlenecks.
-> Style, Code Standards, and Readability
Developers tend to think about how to solve a particular problem in the most efficient or interesting way. They tend to forget that the most important thing in building an application that will be used and supported is maintainability.
The first thing you should always do when building any app is select or create style and coding guidelines. If you do not have one, Macromedia’s internal Web development group has published their ColdFusion Coding Guidelines at http://livedocs.macromedia.com/wtg/public/coding_standards/contents.html. Regardless of what you choose, you need to make sure everyone in your development team adheres to it. Also remember that nothing ever stays in stasis and at times it makes sense to change your guidelines. When you do, be extra rigorous to make sure that people switch to the new guidelines.
Creating clean and understandable code is an art in itself and in most Web applications is far more important than creating the most efficient code. The reason for this is that with almost all Web applications, performance problems can be dealt with at a hardware and networking level, as long as your code and database are reasonably well designed (also, in my experience most performance issues reside at the database level). It is almost always easier to solve performance issues with more hardware than it is to try to rewrite your code to be more efficient. Also, hardware is a fixed capital cost, but labor isn’t. In almost every project, labor associated with development is the single largest expense.
Furthermore, as applications grow and change over time, the underlying code often needs to be changed. Having code that does not conform to a documented standard makes it harder to collaborate and support any system regardless if it’s ColdFusion or COBOL. While rigorous documentation can add to your development time, sometimes it actually speeds up development dramatically in that you actually know what you need to do when you sit down in front of your computer. Regardless, it's more than worth the effort to document your system to make it easier to support in the future.
-> Think Before You Code
Before you ever write a line of code you should have a clear understanding of what you’re about to do. There are many approaches to creating requirements, modeling systems, developing methodologies, etc. However, CF allows for such ease of development that many people start coding without clearly thinking about what the application needs to do. What’s worse they tend to come back at a later date and slap on more code to create new features, without planning or thinking through what effects those changes will have on the system as a whole.
Before you start to work on your application you should create wireframe diagrams, logical flowcharts, and plainly written descriptions of what the application needs to do. You also need to document what your user is expected or required to do at each point in the processes that require user interaction. There is a large variety of methodologies for describing software systems, and some are very intense and demanding, such as the Universal Modeling Language and Unified Process. Others are much more flexible and easy to use, such as those described as Extreme Programming. Regardless of what you use, you should adopt some method of designing and describing your application and follow it all the time.
Most important, don't reinvent the wheel. If you're working on a problem and think it's something that people must have run into before, you're probably right. Make sure to use the tag libraries, your local user group e-mail list, and resources like CFCzone.org, CFlib.org, CFComet.com, Macromedia Dev Center, etc. Good programmers will always use or reuse good code when possible so they can focus on developing the application as a whole.
-> Exception Handling
People have different definitions of what exception handling is, and often make it synonymous with error trapping. In this article I will differentiate between simple trapping errors with CFTRY/CATCH blocks versus actually dealing with unexpected or unforeseen events, and creating a process to deal with those events. You can break down exception handling into several distinct categories: trapping, notification, and logging.
Trapping
This is what most people confuse with exception handling, which is the catching or trapping of errors, usually through a CFTRY/CFCATCH block and/or a CFTHROW command. You should use CFTRY/CFCATCH blocks in your code where an error or exception may occur, such as a CFQUERY, in that numerous unexpected things can happen in a query from a query failure to the database being down. Once you have trapped your error, you need to do something with it. The first thing you need to do is logically decide if the error needs to be dealt with in some way such as attempting to retry the failing process or notifying a system administrator.
Notification
Notifying a user of an error or a problem is often a good idea, but sometimes it can be a bad one. Many developers use e-mail to notify administrators of every exception that happens in an application – a classic mistake of beginning developers. In your planning stage you should think through what exceptions you need to notify a user about, or if you need to notify a user based on a threshold.
For example, you may have implemented a site-wide error-trapping system that e-mails a user whenever there is an exception. One day some new code is integrated that causes an exception every time a user comes to the site. Imagine if you have 70,000 users in an hour. You can easily see how this might bring your mail server to its knees, cause huge performance slowdowns in your server, and generally annoy everyone who is on the receiving end of the notification e-mail.
This is why you need to think through your notification and exception-handling strategy, and in this particular case, you may want to implement a threshold strategy where notification is sent based on severity and frequency. In addition, many errors should first be handled by the system and, if possible, the user should never know a problem has occurred. At the very minimum you can define site-wide error handling in the ColdFusion administrator and refer the user back to the home page. Users should never see a "raw" error message not only because it makes them uncomfortable, but also because it can expose information about the system that then creates a security risk. Many "crackers" purposely try to create exceptions in Web applications so that they can try to gather information that they can exploit to get access to the system.
Logging
Many CF developers confuse logging with notification and assume that since CF logs errors, and they have been notified by an error, that is all they need to do. In general, you want to think about what kind of exceptions the system might generate and what you are concerned about, and then log them when they are created. This can help you go back and reduce bottlenecks in your application and find hard-to-reproduce bugs, as well as look for hack attempts at your system. CFMX now makes use of CFLOG, which allows you to easily log your own information about any event you like and is a great way to log additional information about an exception when you trap it.
-> Testing Your Code
Most ColdFusion Developers never really test their code, but would rather build their applications and work on a trial-and-error basis until the users are happy. This often leads to never-ending development cycles as well as bugs that appear after the project has been completed. Testing is a lot more than just making sure that the code runs, or changing features until the client is happy. Good testing can actually allow you to increase the speed with which you develop applications, reduce your frustration level, and increase the long-term maintainability of an application.
Testing forces you to think about the application and what you want your code to do beforehand, by forcing you to write your tests before or in parallel to your application code. If you cannot create a test for your code it often means you don’t have enough information about what you need to develop, and should revisit your design and documentation.
Recently, the concept of unit testing and "test to code" practices have become more popular with ColdFusion, and now there are several useful tools. One of these is CFUnit, which is based on JUnit. It’s available on the Macromedia DevNet Resource Kit (DRK) Volume 3,www.macromedia.com/devnet/mx/coldfusion/articles/cfunit.html. Also, Steve Nelson of Fusebox fame has developed a testing harness for Fusebox developers at www.secretagents.com/index.cfm?&fuseaction=tools.listtools. Finally, there’s an open source ColdFusion testing initiative called ColdUnit, which shows great promise: http://sourceforge.net/projects/coldunit/.
-> Keep Learning
No matter what your level, you need to keep learning and pushing the envelope of your knowledge. Paradigms and practices in software development are always changing just like in any other discipline, and it’s up to you to keep pace. Good programmers are always monitoring best practices, discussing problems with their peers, and learning new programming languages and technologies. One of the great things about ColdFusion is how easy it is to integrate Java, .NET, and XML. Other technologies and many problems that are extremely difficult to deal with using ColdFusion only are trivial when you use another language, but you won’t know that if all you do is focus on ColdFusion. Another great way to learn is to contribute to online discussions, and better yet, to contribute to your local ColdFusion or Macromedia user groups. If you want to learn a topic or really see if you know it, try teaching it to others.
-> Always Use Source Control
Most ColdFusion Developers never use source control – even on large projects! While most ColdFusion developers may not think they need to use source control because their project is small, using source control can save you development time, allow you to track your work efforts, provide valuable backups, and allow you to easily manage many similar projects. This also applies to projects that you’re doing yourself or at home. You’ll save yourself a huge amount of frustration knowing that you can always revert to an earlier version of your code; also, the best time to build these habits is when you’re working on your own. There’s no good reason not to use source control and once you get into the habit, you’ll find it takes no more time to use it than to not use it.
There are many excellent source control products out there, like Borland’s StarTeam product, which is also a great tool for collaborative project development. Make sure to look also at Concurrent Version Control, which is the standard for concurrent version control and is available as a free open source tool from www.cvshome.org/. Windows versions are also available. If you’re not using source control or version control, start now!
Conclusion
Probably the most important point of this whole article, and what differentiates good programmers from average ones, is that good programmers make all the above strategies habits! Many of us apply some or all of the techniques described above in a haphazard manner, and use them when it’s convenient or when there is no pressure. Really good ColdFusion Programmers do them as a matter of habit no matter what the pressures or time constraints are. The best way to improve as a developer is to always apply the same standards in development no matter the size of the project, even if you’re just coding for fun.
-> Know the Database
Many ColdFusion developers do not take advantage of the power and features of their database, often trying to solve problems in ColdFusion that are better solved through the use of SQL and or specific features in their database.
The main reason for this is that many CF developers feel the need for more than an understanding of SQL syntax and basic relational database theory. As a CF developer you need to understand that each RDBMS has specific strengths and weaknesses, and powerful tools and features that can make your life easier and your application more scalable and robust. The database may also have features that, if not understood, can make development more difficult.
Make sure you have read up on your particular DB and are at least aware of what it can do for your application. For example, many developers try to port code developed for MS SQL to Oracle, and find their join statements throw exceptions, never realizing that while their SQL is correct in the generic sense, Oracle does not support the Join statement and requires you to use the symbolic representation for a join rather than the literal statement.
When building applications, try to build your data model and data access routines independently of your application code. In Web application projects, it can be impractical to totally abstract the data layer from your code, but even in smaller projects you can write many of your queries independently of your ColdFusion code and use literals in the place of variables. In larger applications, and depending on your architecture, creating CFCs, CF custom tags, or templates that you later include into other code that contains your data access and manipulation code, makes a lot of sense. It allows you to test your SQL, reducing the amount of redundant code written, and increasing code reuse. Finally, it also allows you to use database tools to help analyze your SQL to increase performance and find bottlenecks.
-> Style, Code Standards, and Readability
Developers tend to think about how to solve a particular problem in the most efficient or interesting way. They tend to forget that the most important thing in building an application that will be used and supported is maintainability.
The first thing you should always do when building any app is select or create style and coding guidelines. If you do not have one, Macromedia’s internal Web development group has published their ColdFusion Coding Guidelines at http://livedocs.macromedia.com/wtg/public/coding_standards/contents.html. Regardless of what you choose, you need to make sure everyone in your development team adheres to it. Also remember that nothing ever stays in stasis and at times it makes sense to change your guidelines. When you do, be extra rigorous to make sure that people switch to the new guidelines.
Creating clean and understandable code is an art in itself and in most Web applications is far more important than creating the most efficient code. The reason for this is that with almost all Web applications, performance problems can be dealt with at a hardware and networking level, as long as your code and database are reasonably well designed (also, in my experience most performance issues reside at the database level). It is almost always easier to solve performance issues with more hardware than it is to try to rewrite your code to be more efficient. Also, hardware is a fixed capital cost, but labor isn’t. In almost every project, labor associated with development is the single largest expense.
Furthermore, as applications grow and change over time, the underlying code often needs to be changed. Having code that does not conform to a documented standard makes it harder to collaborate and support any system regardless if it’s ColdFusion or COBOL. While rigorous documentation can add to your development time, sometimes it actually speeds up development dramatically in that you actually know what you need to do when you sit down in front of your computer. Regardless, it's more than worth the effort to document your system to make it easier to support in the future.
-> Think Before You Code
Before you ever write a line of code you should have a clear understanding of what you’re about to do. There are many approaches to creating requirements, modeling systems, developing methodologies, etc. However, CF allows for such ease of development that many people start coding without clearly thinking about what the application needs to do. What’s worse they tend to come back at a later date and slap on more code to create new features, without planning or thinking through what effects those changes will have on the system as a whole.
Before you start to work on your application you should create wireframe diagrams, logical flowcharts, and plainly written descriptions of what the application needs to do. You also need to document what your user is expected or required to do at each point in the processes that require user interaction. There is a large variety of methodologies for describing software systems, and some are very intense and demanding, such as the Universal Modeling Language and Unified Process. Others are much more flexible and easy to use, such as those described as Extreme Programming. Regardless of what you use, you should adopt some method of designing and describing your application and follow it all the time.
Most important, don't reinvent the wheel. If you're working on a problem and think it's something that people must have run into before, you're probably right. Make sure to use the tag libraries, your local user group e-mail list, and resources like CFCzone.org, CFlib.org, CFComet.com, Macromedia Dev Center, etc. Good programmers will always use or reuse good code when possible so they can focus on developing the application as a whole.
-> Exception Handling
People have different definitions of what exception handling is, and often make it synonymous with error trapping. In this article I will differentiate between simple trapping errors with CFTRY/CATCH blocks versus actually dealing with unexpected or unforeseen events, and creating a process to deal with those events. You can break down exception handling into several distinct categories: trapping, notification, and logging.
Trapping
This is what most people confuse with exception handling, which is the catching or trapping of errors, usually through a CFTRY/CFCATCH block and/or a CFTHROW command. You should use CFTRY/CFCATCH blocks in your code where an error or exception may occur, such as a CFQUERY, in that numerous unexpected things can happen in a query from a query failure to the database being down. Once you have trapped your error, you need to do something with it. The first thing you need to do is logically decide if the error needs to be dealt with in some way such as attempting to retry the failing process or notifying a system administrator.
Notification
Notifying a user of an error or a problem is often a good idea, but sometimes it can be a bad one. Many developers use e-mail to notify administrators of every exception that happens in an application – a classic mistake of beginning developers. In your planning stage you should think through what exceptions you need to notify a user about, or if you need to notify a user based on a threshold.
For example, you may have implemented a site-wide error-trapping system that e-mails a user whenever there is an exception. One day some new code is integrated that causes an exception every time a user comes to the site. Imagine if you have 70,000 users in an hour. You can easily see how this might bring your mail server to its knees, cause huge performance slowdowns in your server, and generally annoy everyone who is on the receiving end of the notification e-mail.
This is why you need to think through your notification and exception-handling strategy, and in this particular case, you may want to implement a threshold strategy where notification is sent based on severity and frequency. In addition, many errors should first be handled by the system and, if possible, the user should never know a problem has occurred. At the very minimum you can define site-wide error handling in the ColdFusion administrator and refer the user back to the home page. Users should never see a "raw" error message not only because it makes them uncomfortable, but also because it can expose information about the system that then creates a security risk. Many "crackers" purposely try to create exceptions in Web applications so that they can try to gather information that they can exploit to get access to the system.
Logging
Many CF developers confuse logging with notification and assume that since CF logs errors, and they have been notified by an error, that is all they need to do. In general, you want to think about what kind of exceptions the system might generate and what you are concerned about, and then log them when they are created. This can help you go back and reduce bottlenecks in your application and find hard-to-reproduce bugs, as well as look for hack attempts at your system. CFMX now makes use of CFLOG, which allows you to easily log your own information about any event you like and is a great way to log additional information about an exception when you trap it.
-> Testing Your Code
Most ColdFusion Developers never really test their code, but would rather build their applications and work on a trial-and-error basis until the users are happy. This often leads to never-ending development cycles as well as bugs that appear after the project has been completed. Testing is a lot more than just making sure that the code runs, or changing features until the client is happy. Good testing can actually allow you to increase the speed with which you develop applications, reduce your frustration level, and increase the long-term maintainability of an application.
Testing forces you to think about the application and what you want your code to do beforehand, by forcing you to write your tests before or in parallel to your application code. If you cannot create a test for your code it often means you don’t have enough information about what you need to develop, and should revisit your design and documentation.
Recently, the concept of unit testing and "test to code" practices have become more popular with ColdFusion, and now there are several useful tools. One of these is CFUnit, which is based on JUnit. It’s available on the Macromedia DevNet Resource Kit (DRK) Volume 3,www.macromedia.com/devnet/mx/coldfusion/articles/cfunit.html. Also, Steve Nelson of Fusebox fame has developed a testing harness for Fusebox developers at www.secretagents.com/index.cfm?&fuseaction=tools.listtools. Finally, there’s an open source ColdFusion testing initiative called ColdUnit, which shows great promise: http://sourceforge.net/projects/coldunit/.
-> Keep Learning
No matter what your level, you need to keep learning and pushing the envelope of your knowledge. Paradigms and practices in software development are always changing just like in any other discipline, and it’s up to you to keep pace. Good programmers are always monitoring best practices, discussing problems with their peers, and learning new programming languages and technologies. One of the great things about ColdFusion is how easy it is to integrate Java, .NET, and XML. Other technologies and many problems that are extremely difficult to deal with using ColdFusion only are trivial when you use another language, but you won’t know that if all you do is focus on ColdFusion. Another great way to learn is to contribute to online discussions, and better yet, to contribute to your local ColdFusion or Macromedia user groups. If you want to learn a topic or really see if you know it, try teaching it to others.
-> Always Use Source Control
Most ColdFusion Developers never use source control – even on large projects! While most ColdFusion developers may not think they need to use source control because their project is small, using source control can save you development time, allow you to track your work efforts, provide valuable backups, and allow you to easily manage many similar projects. This also applies to projects that you’re doing yourself or at home. You’ll save yourself a huge amount of frustration knowing that you can always revert to an earlier version of your code; also, the best time to build these habits is when you’re working on your own. There’s no good reason not to use source control and once you get into the habit, you’ll find it takes no more time to use it than to not use it.
There are many excellent source control products out there, like Borland’s StarTeam product, which is also a great tool for collaborative project development. Make sure to look also at Concurrent Version Control, which is the standard for concurrent version control and is available as a free open source tool from www.cvshome.org/. Windows versions are also available. If you’re not using source control or version control, start now!
Conclusion
Probably the most important point of this whole article, and what differentiates good programmers from average ones, is that good programmers make all the above strategies habits! Many of us apply some or all of the techniques described above in a haphazard manner, and use them when it’s convenient or when there is no pressure. Really good ColdFusion Programmers do them as a matter of habit no matter what the pressures or time constraints are. The best way to improve as a developer is to always apply the same standards in development no matter the size of the project, even if you’re just coding for fun.
More Information visit ColdFusion Development Services.
