Top Ten Coldfusion Programming Mistakes [duplicate]

This question already has answers here: Closed 12 years ago.

Possible Duplicate:

Common programming mistakes for ColdFusion programmer to avoid?

The purpose of this question is to educate myself, the people I work with, and perhaps other coldfusion programmer's out there..开发者_开发百科

For those of you who program in Adobe ColdFusion or have programmed in ColdFusion, what are the top ten mistakes that you made, or that should never be made.

I mean give me the worst of the worst, must never do, what to avoid.

Sometimes it helps to show "What To Do" well now I want to show "What Not To Do"

Or perhaps share some of your coding nightmares...

bring it on!

---

1. Programming as if you're the only one who will ever work on the code
2. No comments about complicated or strange sections of code
3. Using pound signs (#) unnecessarily
4. Not using cfbreak to break out of a loop when appropriate
5. Using CustomTags for "Business Logic", when a CFC would be more appropriate
6. Not caching singleton CFCs in the Application or Server scope
7. Paginating large recordsets in ColdFusion, when the pagination should be done in the SQL
8. Not setting output="false" on CFCs and each cffunction within
9. Creating arrays of Objects on a high-traffic site when a simple recordset (query object) would perform better and simplify
10. Putting too much logic in the View layer

---

A starter set:

• Scope local variables
• Use CFQUERYPARAM
• Do not reload the application scope on every request
• Do not use application scope for request or session specific data
• Do not store sensitive data (userID, password, username, etc) in cookies. Use session or client scope.
• Use a database for client variables
• Cache frequently-used or slow-changing queries
• If HTML/CSS/etc. is not dynamic, store or cache the generated code
• Let your DB do as much data processing as possible
• Never, ever, leave robust errors enabled on production boxes
• Alsays, always have more than one environment; don't code on the production box.

---

To add to the nice list above by Ben - turn off debugging on production boxes.

---

Others have touched on this but it bears putting out there in greater detail for any cf newbs who might stumble on this. Always use cfqueryparam!

Do not do this:

<cfquery name="getSome" datasource="myDB">
  select * from users
  where userID = '#url.userID#'
</cfquery>

Instead, do this:

<cfquery name="getSome" datasource="myDB">
  select * from users
  where userID = <cfqueryparam value="#url.userID#" cfsqltype="CF_SQL_INTEGER">
</cfquery>

Here is a tool (cfqueryparam scanner) that will help you find if you have any vulnerable queries.

The other thing is, if you're a newb and you are not sure if your app is secure, try the free Hack My CF tool, it helped me a ton. (Not affiliated w/ the site in any way, fyi)

---

What NOT to do eh? Here's 3 that I can think of straight away:

1. If you use try/catch, don't leave the catch not doing anything, especially on large blocks of code.
2. Don't use Evaluate - 99.5% of the time it's not required.

3. Don't use dynamic varaibles, especially when they're set by the URL scope e.g.

   <cfset #url.value# = url.dontdothis> <!--- ?value=application.dsn anyone? --->

---

Don't store passwords as plain text.

---

I just wrote a new set of coding standards for my company that covers a LOT of this type of thing. I'll post something here and/or on my site later.

---

On Windows servers, leaving the default Client Variables datasource. It will trash your registry.