[thelist] CF: Error Trapping: Tip & RFC

[jeff]

joshua,

:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
: From: Joshua OIson
:
: I think you might've missed my point.  The advise
: was given in the original to use cfparam liberally
: for error avoidance.  My point is, if you are given
: the option to use either cfset or cfparam, go for
: cfset.  You will encounter times when you *know*
: that a variable is not set and it needs to be, like in
: application.cfm, and times when you don't care
: what it was before, but need it to be something
: in particular right now..  I've seen variable cfparam'd
: in there when you know without a doubt that this
: is the first time a variable is being used.  So, go for
: cfset, because it is faster, that's all.
:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

if speed is your primary concern, then yes i'd say you're right.  however,
what kind of a speed penalty are we talking about for using a cfparam
instead?  i'm sure it's hardly even measurable except in extreme situations.

personally, my preference is to use cfparam to set up variables and their
defaults and use cfset *only* when i'm changing the value of a variable.
that way when i come back and look at it later i know which action i
intended the code to take based on whether i used cfparam or cfset.

what can i say, i'll always argue readability and maintainability over
performance any day (so long as the performance for that readability and
maintainability isn't too great).

:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
: I'm not advocating isDefined, though I disagree with
: your dogmatic stance on the issue... but we won't go there.
:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

don't worry.  i won't go there either.

next thing on my list to picket?

evaluate()

ready?

.jeff

name://jeff.howden
game://web.development
http://www.evolt.org/
mailto:jeff at members.evolt.org