Yes, I agree. I said "not necessary" does not mean it is not preferable.

Anyhow, if we are coding for our own project, our code will not create any problem for others. If our code is to be used by others, particularly for our clients and public users, such traps are unacceptable.

Unfortunately, such problems can easily be found in the xBase code of built-in VFP power tools. I hope we can see improvement in Sedna.



>>I hope Garrett Fitzgerald won't mind I quote his blog here:
>>http://blog.donnael.com/2006/02/dangers-of-not-using-naming.html
>>
>>I don't agree that applying a naming convention is the proper solution to the issue reported in the blog. The issue should be addressed by applying the "m." prefix.
>>
>>Garrett, a VFP expert, spent 15 minutes in finding the problem. Imagine an average (or below) VFP programmer gets unexpected problem when he runs the VFP RI Builder. He may never know the problem is caused by a name conflict between his table field "TcNewValue" and the variable "tcNewValue" of the VFP RI Builder.
>>
>>My opinion:
>> When we are coding for our own project, "m." is not necessary.
>> If the code is going to work with others' (clients or public users) tables or codes, the "m." prefix is necessary.
>>
>>I hope the xBASE (VFP) code of Sedna won't have similar traps (if we don't call it bugs).
>
>How about, for consistency, you apply the mdot in both cases? It's faster and it's safer.