>>

if lExpr = .t.

>>is identical to
>>

if lExpr

>
>In certain cases I use the above notation. In what cases? In cases where I want the reader to read natural English "IF THIS IS TRUE" or "IF THIS IS FALSE" rather than computer logic language.

Depends what your naming convention is. If you have a logical field with a generic name like "action", "order", "link" etc, both "if action" and "if action=.t." will be ambiguos and hard to understand, specially in English, when they can be both verbs and nouns.

I prefer to name my logical properties and variables with verbs, in past tense if it's some kind of status, or... well, like this:

.lDoReverse - means the reverse should be done
.DoReverse() - a method
.lReversed - means reverse was done
.lIsReverse - means this one is in reverse
.lHasReverse - this one can be reversed
llNoneFound
llIsAPhoto - if it isn't, it's handled by a different method

For field names, I try to stick to the same convention. Now imagine any of these in an iif() - adding =.t. would be redundant, because it would read as "if is a photo is true" - which doesn't sound too English; "if is a photo" is closer.

"If this is true" is said only when you have previously said something, then mention it as "this". However, in code you have an expression, which is a variable, property, field, function, method call... none of which are logical expressions in English. In case of generic names, "if order is true" is just equally unreadable as "if order", and "if lSomeFunction() is true" - sounds like "if it's a true function".

IOW, this isn't English, it's Fox code. It may sound English, but its grammar is Fox. We may tweak it here and there to sound even more English, but IMO a good naming convention gets you more mileage.