0
\$\begingroup\$

I am considering

        <input type="checkbox" name="arConfig[3]" value="payout"  
            <cfif ListFind(attributes.config[3], "payout") NEQ 0>checked="checked"</cfif>  /> Payout<br />
        <input type="checkbox" name="arConfig[3]" value="points"  
            <cfif ListFind(attributes.config[3], "points") NEQ 0>checked="checked"</cfif>  /> Points<br />
        <input type="checkbox" name="arConfig[3]" value="quarter" 
            <cfif ListFind(attributes.config[3], "quarter") NEQ 0>checked="checked"</cfif>  /> Quarter<br />

Vs

        <input type="checkbox" name="arConfig[3]" value="payout"  
             <cfif ListFind(attributes.config[3], "payout") GT 0>checked="checked"</cfif>  /> Payout<br />
        <input type="checkbox" name="arConfig[3]" value="points"  
             <cfif ListFind(attributes.config[3], "points") GT 0>checked="checked"</cfif>  /> Points<br />
        <input type="checkbox" name="arConfig[3]" value="quarter" 
             <cfif ListFind(attributes.config[3], "quarter") GT 0>checked="checked"</cfif>  /> Quarter<br />

Which is clearer the NEQ 0 or the GT 0 ?

\$\endgroup\$
5
\$\begingroup\$

You don't care what the numeric value here is, so don't test for it. You want a boolean, and I think the listFind() call is semantically boolean itself without the comparison.

So: "neither". Do this instead:

<cfif ListFind(attributes.config[3], "payout")>

Either/any option looks pretty cluttered as it is, so given yer repeating the same string except for the difference of the value, I'd put that lot in a loop over the values too, maybe?

\$\endgroup\$
2
\$\begingroup\$

Just a note: As a personal rule for booleans, I've always found it better to check for NOT FALSE rather than a TRUE value (though in this situation, I 100% agree with Adam's answer). FALSE will pretty much always be a 0, but TRUE can be anything not 0. ( You'd think that Microsoft could have coordinated its definition of TRUE between SQL Server and Access. :-S )

\$\endgroup\$
  • \$\begingroup\$ Good point. Forgetting that most non-zero values equate to true can easily lead to inadvertent logic errors. That said, I still prefer expressing conditionals in the positive (if feasible) :-). It is just more natural and intuitive IMO. \$\endgroup\$ – Leigh Sep 13 '16 at 19:16
  • \$\begingroup\$ @Leigh I completely agree with it being more natural to look at a true value. However, I've been smacked before looking for true when I had people editing values in a SQL Server database with an Access interface. I didn't know they were using Access, so it was fun figuring out how my "boolean"s were getting flipped to -1 instead of 1. Though that problem is likely as much to do with bad initial db setup. We had big discussions about why a boolean field should be a bit instead of a nullable int. :-/ \$\endgroup\$ – Shawn Sep 14 '16 at 19:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.