Agreed - I avoid double negation at all costs!

Should not have used this example as it is open to criticism...in this case, done because:

a) the naming matched how the users talked about their contacts already; I always try to name data the way they typically use it (unless it causes a real problem)

b) back when table was set up, the framework was "klunky" for defaulting table values - it was easier to have a "Deactivated" field that defaults to .F. when a contact is added.

Just the way it was when these tables were set up 25 years ago...

Albert

>Double negation is even worse… if userActive! ;)
>
>>I do *try* to do the positive one first but I really like the one that most commonly runs to also be first - especially if there is a lot of code for this condition. I know that the general "rule" is to try to avoid negatives.
>>
>>

>>IF NOT UserDeactivated
>>  && do first as 99% of the time user is not deactivated
>>  && lots of code here; I want to read it first usually (and execute the fastest, though probably this is so negligible in most cases it does not matter)
>>ELSE
>>  && user deactivated; very little code just alert and return
>>ENDIF
>>
>>

>>
>>And yes, I do just about always comment the ELSE and also the ENDIF - especially if they are nested as it helps me see what ends where.
>>
>>Thanks.
>>
>>Albert
>>
>>
>>>1. if both alternatives are processed, you may want to write the positive comparison first:
>>>

>>>if myFlag
>>>else
>>>endif
>>>

>>>
>>>2. explicit naming makes it more readable:
>>>

>>>if success
>>>else && error
>>>endif
>>>