I like to think of it as practising "safe programming".

You can significantly reduce the potential for surprises in the way VFP handles fields/memvars by running as much as possible with NO work area (alias) selected as current.

A field name ALWAYS takes precedence - field names in the current 'active' work area that is.
This can bite in untold ways. A parameter name, for instance, can suddenly change from being a memvar to a field **if** a new fieeld is added to the table that is active that matches the parameter name.
The same of course can happen for any memvar, not just a parameter name.

By using the "m." explicitly when required (or even when not specifically required) you preclude sudden surprises caused by matching field names in tables.

cheers


>Hello all
>
>This is by way of a general discussion and query. It has long come to my notice that many of you use the memory var m. thing, even the most esteemed of our experts. Some years ago I read an article about this and I wish I knew how to get hold of it.
>
>The gist of the argument was essentially that the m. construct was not necessary and, in some cases, less efficient. For instance, when assigning values to a var, it's no use in distinguishing between a table field and a memory var of the same name, because one always uses "REPLACE" for fields anyway. Of course, if there are a field and var of the same name (and assuming the field's table is currently selected anyway) then it is useful for distinguishing in cases of comparison. But that's the only advantage I can see.
>
>I recall the m. as a throw-back to the old dBASE days and, personally I never use it. Does anyone have an argument for its use? Can anyone put their finger on the article to which I referred?
>
>Just curious
>
>Terry