Skip to main content
M
mega_L
Inspiring
September 10, 2009
Answered

Still not too clear with cfif NOT

  • September 10, 2009
  • 2 replies
  • 5049 views

Someone told me long time ago that it is better not to use <CFIF SomeVariable NEQ ""> which I have used a lot in my codes

It is much better when using <CFIF NOT SomeVariable> instead

Am I remember this correctly?

This topic has been closed for replies.
Correct answer ilssac

Are you wishing to discuss the merits of <cfif something NEQ ""> versus <cfif NOT something EQ "">

OR

Do you wish to discuss the merits of <cfif something> versus <cfif something = ""> versus <cfsomething EQ true> etc.

----------

The former is largely style choices and I know of no preformance reason to choose one or the other.

The latter depends a bit on the nature of the variable.  If the variable is a true boolean and would have a value of true or false, then I see litte difference between <cfif aBoolean> and <cfif aBoolean EQ true>.  Some do argue that the latter is a bit more explicit on what the intention is.  The only danger with counting on the variable being a boolean is that ColdFusion is typless and it is possible that a variable one expects to be a boolean got redefined somewhere along the way and is something different.

If the variable is not a boolean then ColdFusion is going to try and cast it as one if you just do <cfif aVariable>.  The danger here is that it may cast it in a way that the programmer did not anticipate.  Empty strings and numeric 0 will consitstantly be cast as false.  But it could be dangerous to count on this.  I think the general consensus is to be clear about what you intend and to define what is or is not a true or false condition.

2 replies

BKBK
Community Expert
BKBKCommunity Expert
Community Expert
September 10, 2009

In Coldfusion, <CFIF SomeVariable NEQ ""> is equivalent to <CFIF NOT SomeVariable EQ "">. Don't let anyone tell you different.

There is one such place I know where there is a big difference. That is, when booleans are involved. The line <CFIF someBooleanVariable> is much better than <CFIF someBooleanVariable is true>.

ilssac
ilssacCorrect answer
Inspiring
September 10, 2009

Are you wishing to discuss the merits of <cfif something NEQ ""> versus <cfif NOT something EQ "">

OR

Do you wish to discuss the merits of <cfif something> versus <cfif something = ""> versus <cfsomething EQ true> etc.

----------

The former is largely style choices and I know of no preformance reason to choose one or the other.

The latter depends a bit on the nature of the variable.  If the variable is a true boolean and would have a value of true or false, then I see litte difference between <cfif aBoolean> and <cfif aBoolean EQ true>.  Some do argue that the latter is a bit more explicit on what the intention is.  The only danger with counting on the variable being a boolean is that ColdFusion is typless and it is possible that a variable one expects to be a boolean got redefined somewhere along the way and is something different.

If the variable is not a boolean then ColdFusion is going to try and cast it as one if you just do <cfif aVariable>.  The danger here is that it may cast it in a way that the programmer did not anticipate.  Empty strings and numeric 0 will consitstantly be cast as false.  But it could be dangerous to count on this.  I think the general consensus is to be clear about what you intend and to define what is or is not a true or false condition.

M
mega_LAuthor
Inspiring
September 10, 2009

I guess I was confused between the 2 of them.

Currently I'm using <CFIF something NEQ ""> do something  <CFELSE>  do something else </CFIF>

Thanks for the explanation

A
Adam Cameron.
Inspiring
September 10, 2009

I guess I was confused between the 2 of them.

Currently I'm using <CFIF something NEQ ""> do something  <CFELSE>  do something else </CFIF>

Taking the <cfif> part in isolation, I would err more towards "x NEQ y" than "NOT x EQ y" because the former strikes me as being closer to the way one would express the idea (at least in English), so it's easier to understand when reading the code.  It's also slightly vague as to whether the latter means "NOT (x EQ y)" or "(NOT x) EQ y", which are two different things.  CF will resolve this with its order of ops rules, and provided one knows what those are: fine.  However it's an extra mental step to understand the code.

Boolean ops are very fast, so any performance considerations here would be so trivial as to not be worth worrying about, in the bigger scheme of things.

However once you introduce the ELSE part into the equation, my opinion changes.  I would generally try to avoid a negative test in an IF/ELSE construct, instead wording the test positively.  Human brains parse positive expressions faster than negative ones.  So if you had this:

<cfif negative test>

     block1

<cfelse>

     block2

</cfif>

I would refactor that as

<cfif test>

     block2

<cfelse>

     block1

</cfif>

Then again, there are definitely situations in which the logic is more easily understood doing a negative test, so sometimes I stick with it.  I guess if the test is overwhelmingly likely to be a negative result, I'd construct the code block to present the most-likely-to-run code first. wording the test accordingly.

--

Adam

Terms & ConditionsAccessibility statement
Using the community Terms of use Privacy Cookie preferences Do not sell or share my personal information ad choicesAdChoices