>>>The risk is not for tables. The risk is in naming variables that may conflict with field names, and your program processing the wrong values. Do you have a convention for naming variables that guarantees that no variable name ever will conflict with a field name of a cursor open in the current datasession?
>>
>>Absolutely,
>>
>...
>
>What is your naming convention for variables?
>
>...
>>I do have control over that. If they are following the naming conventions for variable and fieldnames such conflict would never occur.
>>If they screw up they have a lot to explain, because naming your variables the same as the fieldnames should never occur.
>>
>...
>>>Walter, the point here is that you should use mdot in addition to your conventions, not in place of.
>>
>>That is my choice. What I'm saying is that people need to apply a first line of defense by naming variables and fieldnames using a different convention.
>>Sorry but anyone pointing that I should use mdot and dismisses the need to use naming convention should not be taken seriously IMO.
>
>Your conventions are part of your enterprise/project culture. The mdot would be in addition to that. Call it an additional line of defense, if you will. We're going in circles here.
>

Are you really asking me to add mdot to my source code on the basis of false safety of a problem we have never encountered?
Something like, if it aint broke, fix it until it is ?


>>I've been working with this naming convention for over 20 years and never had any conflict on this matter, nor my fellow programmers working on the same project.
>>... Again I should mention this project involves more than 2 million lines of code, an EMR used by top medical centers on 5 continents where a small team of developers (of which a few very well known UT members) are working upon.
>>If this was an issue, I would have seen the problem at least once would I ?
>
>>The bigger issue is to make sure programmers everywhere are producing the same quality level of code and make sure they are using the same naming conventions.

>The number of people and number of lines of code are irrelevant. I, too, have huge healthcare apps with millions of lines of code. That does not prevent me from introducing new (or not so new) concepts that make sense.
>I inserted the word in bold in your sentence above. In other languages/dev environments, the compiler may have additional options for enforcing that discipline. In VFP we don't have that luxury, so it is the programmer who has to apply it.

It does not belong there. its foolish to think you get all developers everywhere to adhere the same coding conventions. You'll have to accept that companies have their own.
You cannot force you're opinion, even if it shared by many people down into someone else his throat.


> If you need a lengthy wikitopic to explain where to use it and where not you really have to wonder whether this mdot is not just one big screwup (when they designed xBase)
>
>The discussion on wiki is useful for its conclusion. You don't need to wonder where you should use mdot and where not. You can use it everywhere, with very few exceptions that are really extreme cases that require additional attention. Thierry and Naoto have pointed to them in previous replies.


My conclusion on the topic is that you'd better find another way of avoiding the fieldname/variable conflict because realy if you need to know all of this in order to create some code, you should realise that No-one is going to be able to adhere to this standard. And really the source code at VFPx is proving that I'm right in that.