Tuesday, September 07, 2004

Error Proofing Your Code

The best way to start error-proofing your code is by following these steps:

1. Identify every incoming piece of data, and document it and it's datatype
2. Identify any possible conflict issue between different scopes of data either incoming or created by the application.
3. Then document each section of your app, with the above information, so you can tackle your app 1 step at a time.

Now that you have the documentation, now comes the setup.

First of all, in my personal style and attempt to prevent scope creep, I came up with my own variable naming scope.

For any application, at the top of the page i create a list of variables that are going to be used within the app, as well as incoming data.

!-- global variables --
cfparam name="local_firstname" default=""
cfparam name="local_lastname" default=""
cfparam name="local_price" default="0.00" scale="2"

Then i move all cfparams through out the application, to the top of the app, for easier sorting and eliminating duplicates.

Now then comes the population from wherever your datasource is: url, form, query, cgi, file, client, cookie or local.

Then you put a cfoutput surrounding the whole form, then you have created an error proof form.

Let me explain.

By having a default values for every form element, you make sure that the form can be used either for an edit content or add content piece. Which really speeds up the process of creating forms.

Now all of this is part of my philosophy of preventing errors from occuring in the first place, rather than trying to catch for them.

I'll walk thru a section of an app, and try to identify places it can fail, and do what i can to prevent it.

More to come...


  1. I hope you are joking? If you still need all of the mentioned steps beside the already dummy proof ColdFusion error message details, then people rather need new glasses ;)

  2. You are missing the point, instead of creating code that prevents any of your customers from seeing errors in the first place.

  3. You are hoping that cfcatch and cftry will deliver a good experience to your client.

    It's time for us to stop being coding cowboy's and really think and plan for our applications.

    And that includes planning to prevent errors. It takes hard work, but it's worth it.

    I am not saying it is easy, but as a customer I'd rather never see any error messages, because it took a little longer, than some rushed in code.

  4. Anonymous8:21 AM

    "Then you put a cfoutput surrounding the whole form, then you have created an error proof form."

    This is absolutely not true. Look at what you are doing, setting a default price of 0.00? Do you not see the giant flaw in this logic? Yes your page might execute and you don't get a CF error, but that in no way means that the code is running correctly! So the user is looking at a nice new iPod in your store but something goes wrong and a price is not generated. In your app, everything would keep working and the iPod would cost $0!!!

    Reusing forms for editing and updating is often a good idea, but using this approach to fool yourself into thinking that just because no error was thrown that everything is ok is a recipe for disaster.

  5. Anonymous8:46 AM

    I have yet to have many variable scoping conflicts with my CF apps -- I think you're big-noting something that is really quite basic.

    I think more relevant guides to preventing scope related errors are:
    - Use cfparam on .cfm pages
    - Use cfparam on attributes in custom tags
    - Use var religiously for local vars in CFCs (those created by you or by cf tags)
    - Use variables and init methods properly in CFCs
    - Use StructKeyExists rather than IsDefined

    I don't think its at all necessary to plug on "local_" on the front of all your variables. Especially since your comment refers to them as "global".

    A more sensible naming scheme if you were to adopt one is to plug on the abbreviation of the type of the variable (which can sometimes help reduce logic errors when using a loosely typed language such as CF). For example; a structure containing contact details could be named "stContact".

    I recommend just sticking with Sean Corfield's MM Web Team Coding Standards.

    -- tim lucas

  6. Craig why not just follow the Fusedoc practices that Hal and I have been touting for years?

  7. Anonymous10:14 AM

    This blog should be called "how NOT to program in ColdFusion."

    By "CF-Purist" does that mean that you shun the use of ColdFusion components?

  8. Anonymous11:26 AM

    "Then i move all cfparams through out the application, to the top of the app, for easier sorting and eliminating duplicates"

    are you serious????? WTF????

  9. Regarding cfparam locations, it's much easier to read having all your default variable setups, at the top of the app. That way it is much easier to read.

    By coldfusion purity, i am trying to pass on whatever I can, from my own experiences, that make sense, and that are of value to other people.

    In most of my career, I have been in the position of cleaning up ugly, code, so I have adapted my own style in how organize the code for easier reading, and logic flowing...

    1. I come up with my own naming of a locally scoped variable that starts with local_, for example local_firstname. This helps me remember what scope it is, and then i can choose what scope to populate or not populate it.

    2. Whenever i create a content piece, I create the edit portion first, then I can easily copy it to the add piece, because I use local_ in my code. You, of course can use your own standard, this is just a side benefit to using a variable naming convention that is seperate from the ones created by each scope.

    The goal of this is to help prevent errors by having predefined variables with default variables.

    The benefit is in the less steps of logic

    instead of isdefined() and then if url.whatever is greater than 0 or null then update the variable, you can simplify.

    To if local_whatever gt "" then do x

    That's what I am trying to across.

  10. This comment has been removed by a blog administrator.