>>>Totally agree.
>>
>>Acknowledging that all this does come down to personal preference, choosing to not use "m.", for whatever reason, is similar to being so confident that your own revolver is not loaded that you happily put the barrel to your temple and pull the trigger 6 times.
>
>I say, Jim, steady on! I've never used m. and never got outside a bullet for it. Am I wrong in saying xBase is the only language that uses this and all the others seem to get along OK without it?
>
>Cheers
>
>Terry

The difference, as I'm sure you know, is that in VFP you can have fields and variables that may have the same name and can be referenced the same way in code. When that occurs, it causes an ambigous reference. Because VFP is a data-centric language, when a field exists with the same name as a variable, the VFP rule is that a field takes precedence over a memvar to resolve the ambiuous reference. The only way in code to differentiate a memvar from a field with the same name is to use m. An exception to this rule is when it is an assignment, because you "replace" a field and "assign a value" to a variable. When the program logic is expecting the value to come from the memvar, but the contents of the field is read instead, unpredictable errors can occur.

When I write code, expecially reuseable functions and such, I don't always know who where it may be used and what tables may be open. Unless you use a variable naming convention that guarantees that you will NEVER have a field named the same as a variable, m. is your only defense.