RE: [CFCDev] OT: Empty fields passed as integer parameters

[Johnson, Ben R.]

What about using isNumeric() or isDate() for situations like this? Is that good form?   Ben -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]On Behalf Of Peter J. Farrell Sent: Thursday, March 02, 2006 7:27 PM To: CFCDev@cfczone.org Subject: Re: [CFCDev] OT: Empty fields passed as integer parameters Roland Collins said the following on 3/2/2006 5:16 PM: It's subtle, but values that return integers should always be tested against other integers. It's (mildly) bad form to rely on the fact that CF evaluates 0 as false, especially considering that when you think about it, what you're really writing is "0 is false". Implicit conversion or no, doesn't that look odd? null="#Len(form.CustNo) is 0#" is really what you you're trying to test. Also, the YesNoFormat is unnecessary, since all that does is return a string containing "yes" or "no". These are then also implicitly converted into their boolean equivalents. Roland I never use YesNoFormat() - I was running out the door and didn't take the time to write the best reply (should have just let others do it).  I used it for understandability. I don't really think it's bad form per se IMHO.  I understand that NOT Len(..) uses negative logic and that it can be cumbersome for some. I only use it in certain situations and that it might not be best to rely on implicit conversions.  In my defense, CF does not have to make a comparison with an operator (like Len(...) EQ 0 when using negative logic which supposedly would save some cycles over a period of time.  CF resolves 0 to false and anything else as true -- I doubt this will change since the language is typeless.  No sense in testing a boolean with another boolean -- like boolExpr IS true or boolExpr IS false. You may want to use a UDF in this case to encapsulate your logic: <cffunction name="isNull" access="public" returntype="boolean" output="false">     <cfargument name="value" type="string" required="true" />     <cfreturn NOT len(arguments.value)> </cffunction> If my source is correct, these are the implicit conversions for the following languages. Taken from http://www.hal-pc.org/~clyndes/computer-arithmetic/calculations.html Boolean Conversions Most programming languages have some sort of convention which treats non-boolean values as booleans. C treats a zero or null as false, anything else (including the null string) as true. Perl has about seven different values, including the string "0.0" which are treated as equivalent to false. This can lead to subtle bugs. C and C++ programmers often take advantage of the fact that assignment returns a value, and use assignments in tests: while ( a = getc() ) { ... } The loop will continue as long as getc() returns a non-null character. But even experienced programmers will occasionally use the assignment operator, = when they mean the comparison operator == as in: while ( a = 5 ) { ... } resulting in an infinite loop in this case, with the unintended side effect that a is set to five. Java aids the programmer by forbidding the interconversion of booleans with non-booleans, and requiring that control structure tests must return boolean values. I recall this exact conversation last July (2005) with Bill Rawlinson and you (Roland).  So all in all, it really comes down to personal preference is your coding style.  In my mind, NOT Len(...) equates to "I want FALSE" to execute this next block of code in my mind.  Anyways, all the other suggestion are way better than using Len(...) EQ "" IMHO.  That's that and I don't want to sound like I'm want to argue about it, just sort thinking out loud here. Best, .Peter -- Peter J. Farrell :: Maestro Publishing Member Team Mach-II :: Member Team Fusion http://blog.maestropublishing.com Create boilerplate beans and transfer objects for ColdFusion! Fire up a cup of Rooibos! http://rooibos.maestropublishing.com/ ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org with the words 'unsubscribe cfcdev' as the subject of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com). An archive of the CFCDev list is available at www.mail-archive.com/cfcdev@cfczone.org ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org with the words 'unsubscribe cfcdev' as the subject of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com). An archive of the CFCDev list is available at www.mail-archive.com/cfcdev@cfczone.org