>>>SNIP
>>>
>>>>Why do that when it is not necessary, but ignore mdot when it certainly can be necessary?
>>>
>>>If you find yourself that it is necessary, it already is an indication there is something wrong. Column names should not conflict variable names in the first place. Granted, there are situations where this is out of your control, but in general your naming conventions should avoid this at all cost.
>>>
>>>To answer your question directly. For me it affects readability. As like Lutz, I hate it passionately.
>>
>>I don't care what you personally think or do. FoxPro works that way.
>
>That is a nonsensical answer. Coding practices have very little to do with how a product was designed. The latter is a human readable representation of instructions to the mechanics in the programming language.
>
>The fox isn't flawless. With the knowledge we have now it would not have been build in the same way as it is. There is a reason there is a good portion of commands and functions that are not commonly used anymore. The mdot would certainly not be part of VFP if it would not have to rely on its heritage.
>
>So I have no idea, what your implying when you say "FoxPro works that way".

He's saying that FoxPro has a way it disambiguates names and you can work with it (use mdot where it's called for) or you can do it the hard way by having a whole set of rules to try to avoid conflict rather than adapting to reading code with mdot in it.

I prefer the easy way. Yes, I also use naming conventions because they help me and whoever inherits my code, but I don't count on them to ensure that a name in interpreted the right way. I use mdot where it's appropriate, I add IN to commands that allow it, and the alias parameter to functions that accept it, and thus I make my code more likely to do what I want it to.

Tamar