>>>>I agree. The number of cases where I add it are limited. It may well be that it are exactly those cases where I have not paid enough attention to the naming of the variable or function. I'll gonna pay some attention to this.
>>>>
>>>>OTOH, there are also cases where it's harder to add Is, Has, No, None, Do, etc. as a trailer. The clearest example is:

IF THIS.VALUE = .T.

>>>
>>>But then it's in the context of a checkbox or other control with a logical controlsource. I don't put =.t. in there, simply because when I'm reading the code in a checkbox, I know where I am. Elsewhere, I use "if empty(.chkSomething.value)" for "if unchecked", because it also covers the case when checkbox has a numeric controlsource.
>>
>>Perhaps YOU know where you are, but what's the harm of writing = .T. in such a case. Or stated in other words: Would you think derogative of another programmer when you saw such a line in his/her code?
>
>Yes. If I saw that form regularly in the code, I'd think the programmer didn't know it was unnecessary.

Tamar, I'm referring now to the case of THIS.VALUE only, not to all cases. If you'd see that the programmer does not use = .T. in all cases except for the THIS.VALUE cases, would you even then think negative of that programmer?

>That said, I did test this stuff for an Ask Advisor piece a few years (Jan. '06 issue), and found that it doesn't have a performance effect.
>
>However, using an IF to assign a logical value to a variable rather than just assigning the expression was slower.

I often assign a property's value to a local variable that will be used in the rest of that code more times. E.g.

ldStartDate = this.parent.dSDate
for ln = 1 to 10
    ? m.ldStartDate + m.ln
next

One reason is that it gives me the chance to write easier readable code. But also I have the hunch that it may be slower to retrieve this.parent.dSDate x times than the local variable. Is this hunch valid? Or is it just me.