I would argue (after working with a great deal of C++ code) that evaluating zero and non-zero as false and true is just as common as "direct syntax". Most C++ logic blocks are built on exactly this type of "integer logic".
-mk -----Original Message----- From: Dave Watts [mailto:dwatts@;figleaf.com] Sent: Saturday, November 09, 2002 6:10 PM To: CF-Talk Subject: RE: Studio MX > > Pedantry can be dangerous. While Len returns an > > integer, CF treats non-zero integer values as > > boolean "true" values when they're used in boolean > > expressions. > > Yes, so does C and C++ but that doesn't make it good > style, IMO. No, but it doesn't make it "bad" style, either. One of the things that differentiates style from utility is that style really doesn't matter. I'm usually on the other side of the fence in these sorts of arguments, but this, to me, seems about on the same level as how you should use curly braces in C-style languages. I guess James Gosling et al agree with you on this, though. > > Now, you may argue that your explicit syntax is more > > readable, but I'd counter that by saying that any > > competent CF developer should know that integers > > are treated as boolean values. > > As would any C or C++ developer. Again, it doesn't make it > good style. I prefer <cfif len(x) gt 0> as an explicit test > although I probably wouldn't take a developer out and shoot > them for just writing <cfif len(x)>. It is good to know where you stand on the death penalty! > I *would* take them out and shoot them for writing <cfif > not len(x)> which I think is a horribly ugly and easily > misread condition! <cfif len(x) eq 0> is *much* clearer. > I've seen many 'non-programmers' write the equivalent of > 'not len(x)' when they really mean something like 'len(x) > ne 0'! My motto is: be explicit. > > Note: never, ever compare boolean expressions to 0 or 1 > (or false / true), especially to 1 (true). <cfif f(x)> is > not always equivalent to <cfif f(x) eq true> - precisely > because people can be lazy about mixing numbers with real > booleans. Again, I would agree with you on the general concept that explicit, self-documenting code is superior to other code. I just don't see this as making that much of a difference in that direction. Once you learn the simple fact that CF can evaluate integers as boolean values, it's just not that complicated to read. As for what "non-programmers" may write, well, that's a whole other kettle of fish, isn't it? Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ voice: (202) 797-5496 fax: (202) 797-5444 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribe&forumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Get the mailserver that powers this list at http://www.coolfusion.com
