>>If we want the safety, the VFPT must add a SET that it obligates to put mDot for get a variable's value.
>>
>I still don't see a need for a special setting to FORCE the use of Mdot to reference variables. Using Mdot simply removes ambiguity and short circuits the field/variable lookup process to directly access the variable without even considering whether it is a field in the current workarea. VFP might have to first consider whether there is an alias "M" or object "M" but after that litle decision is made, it goes directly to the variable list. Seems like a very logical thing to do.
>
>Without Mdot, there is a "by design" ambiguity that always exists that must be resolved. VFP's "by design" way to resolve this is to look for a field with the referenced name in the current workarea FIRST, then look at all variables that are in scope. If you are referencing the variable but do not use Mdot, you are allowing VFP to work as designed to perform the required lookup to get the value but you are also taking a chance that it may incorrectly access the value from a field instead. Naming conventions can prevent incorrect lookup as long as there
>is NO CHANCE of a field to ever have the same name as your named variables.
>
>Field/Variable access errors can be avoided, but without Mdot, the lookup methodology is BY DESIGN to look at fields FIRST. Using Mdot, you bypass this BY DESIGN behavior and at the same time, for anyone who may be reading your code who may have no idea what fields or variables are in scope, whether you think it is UGLY or not, you remove ALL ambiguity as to what you're referencing.
>
>Use Mdot or Not, I don't care. You should always strive to write good code that works exactly as designed that is easily maintained. It can be done either way. My preference is to use Mdot AND use field/variable naming conventions AND remove all ambiguity. If someone thinks my code is ugly, so be it. It works as designed and is as efficient, readable, documented, maintainable and bug free as I can make it. I can live with that.

Hi Elmar,
I see always arguments that they do not consider the developer's error,
safety for MY errors !

I have an safety much high one of what i think,
but why I be trusted, if I have one stupid machine that can control a part of the errors to my place?

Example:

CREATE CURSOR myCursor (someName I)
APPEND BLANK
SCATTER MEMVAR
someName = 3
innerProc()
* i think  myCursor.someName = oldvalue = 0
* and write
? someName  && with SET STRICTMEMVAR ON this line fire a error

PROCEDURE innerProc
*
* a my program error
USE
ENDPROC

Now, without others side effects, how can you found this bug ?
You found this bug when your customers report to you a mistaken output !

Fabio