>>>>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,
>
>Anyone would know - how do you open a checkbox's method without knowing it's a checkbox?
>
>>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?
>
>No, in this case not really. I was just explaining why I wouldn't write it so, but it's not something I'd frown upon.
>
>In case of a checkbox, however, it did happen to me that I changed my mind about a logical field, and turned it into a n(1) - everything else about a checkbox worked, except code which relied on its .value being logical. Which is how I acquired the habit of using empty(this.value) for checkboxes.

IF EMPTY( THIS.VALUE )

is not a priori natural English, unless reading IF THIS VALUE IS EMPTY is an accurate wording of the functional design. A checked box is a checked box or a positive indication, but it is only seldomly a non-empty value. In other words, your example is not strong in my opinion.