>>[snip]
>>>>[snip]
>>For two, an mdot in front of a keyword like THIS suggests that THIS might also be a field! The reader will likely raise his eyebrows, as an indication of surprise. "Hey," he'll think, "is it possible that there is some table here in this application with a field name THIS?" Confusion is the result.
>
>Unfortunately, you can impose standards on those over whom you have influence, but the world is full of those over whom you have none.

Imposing standards is not my goal. But, ideally, we might try to make some agreements about standards, wordwide indeed. But - read my sig - standards are only okay if they are good. So, I'm not so much interested in standards, no, I'm interested in good standards. Bad standards will only hamper us. There are several anecdotes where I dismissed the standards of a client's in-house developers, only to prevent becoming one more 'untalented', failing developer.

>We may be talking at cross purposes here. It seems to me you want standards around making code more readable, and Fabio wants standards around making his code safe. Those two concepts may not always be mutually inclusive.

I don't know about Fabio's full idea about standards, but mine indeed also appraises other factors then safety alone. To be clear, safety is also a major factor, of course. To some extend you may be right that Fabio and I are talking at cross purposes here. I have pointed to other aspects than safety. He doesn't appear to appreciate the importance of those aspects.

>If you can guarantee that nobody anywhere ever will use 'This' as a field or alias name, then you are ok using such a standard, but if you ever have to work on code written by someone else, then Fabio's 'standard' is a whole lot safer. The way Fabio handles it, he simply cannot have a problem situation in his own code. Doing what you suggest leaves you open to the sad fact that no matter how much you time and energy you put into your standards, some fool will circumvent them. Your code may end up being more readable, and less safe.

I think that 'a whole lot safer' is too much credit. I can live with 'a tiny little bit safer'. When developing standards, 'fool proof' must not be the goal. (You used the word 'fool'. That triggered me in this case.)

>>We, the seniors who educate the starters, should tell them about the mdot issue. We must explain when and why to use the mdot. And it is my strong opinion that we must tell them also that names like THIS are forbidden for field names! In a system that has no field name THIS, it is clear that the mdot is not appropriate in front of THIS.
>
>Forbidding something that you can't enforce has never worked in the past, so I don't hold out much hope for it in the future. When VFP itself forbids using 'This' as a field or alias name, then you can do as you say, but then again, when that happens, Fabio will be able to drop the 'm.' in front of 'This' with no change at all to his standards.

I understand what you're saying. OTOH, it IS a major problem in vfp-land that we have too much idiosyncratic sourcecode. It is one of the reasons why quite many other-language-developers do not have very high esteem of 'us'.
The language is partly responsible for this, not being strong-typed, for example. (I'm not propagating strong-typing here.)

>>The standard should incorporate:
>>- Never create a field with a reserved name like THIS.
>>- Use the mdot in the right argument, but do not use them in front of reserved words like THIS.
>
>>I don't mind that Fabio uses m.this in his own code, although I would not like to read or maintain such code. But I think it's inappropriate that he uses that method here on the UT in his examples. It are the starters who get influenced. And it's a bad influence.
>>
>>Maybe we can vote on THIS ...
>
>I vote that Microsoft prohibit the use of 'This' as a field or alias name. Then... problem solved.

Add my vote. But they'll never do that, because of downward compatibility.