>Calvin in his blog (http://blogs.msdn.com/calvin_hsia/archive/2004/12/14/301282.aspx) clearly explained that why "m." should be used. He also stated that using m. is a way to make code easier to read, easier to maintain, and faster.
>
>It is indefensible, if not unforgivable, that code of many VFP built-in tools written in VFP does not observe the m. rule. These tools will be used in all VFP programmers' work. Nobody will be aware of the existence of the variable "tctable" in VFP's RI Builder when he runs it on a table with exactly the same field name, particularly in tables migrated from FPW apps. It does not make sense to expect users to rename fields before running the tools.
>
>
>Ben

The agree with you.

Classic example:
1.

PROCEDURE XXXX_access
RETURN m.this.XXXX && <== this is a variable

Calvin blog does not speak about the other relative problems you to m.

Example: scatter on a record object and add a computed property:
2.

CREATE CURSOR oneName (secondname I)
SCATTER NAME oneName 
INSERT INTO oneName VALUES (1)
ADDPROPERTY(oneName,"thirdName",DATE())

? oneName.secondname
? m.oneName.secondname
? m.oneName.thirdName
? oneName.thirdName && <= ERROR

We hope that someone of the VFPT is taken of the time and puts the m. where they must be puttinges!

Fabio