>>>... You realize that in your case the risk of conflict grows with every new table (or even query) that you add to your project, and with every new variable name. In other words, your risk of conflict grows no matter what (i.e. when you're coding normally). Mine, only when doing things wrong. Also, in my case there could be one or very few instances raising that risk. Whereas in a project not using mdot, the risk is everywhere.
>
>>The risk for tables is ZERO as each and every table follows the naming convention, since queries do very rarely use realiassed field for the reasons described earlier the problem is realistically non-existant there. Plus the framework is heavily using datasession for the framework objects so no chance of a cursor or table magically pop up there by accident. For developers working implementation of biz objects / forms they just have to adhere to the naming convention and things will me fine.
>
>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,

Above I meant a naming convention for fieldnames.

>>>>If you really want to know that answer I encourage you to go to VFPX and download some sourcecode and analyse it in detail.
>>>I know what you're talking about. And that is why I wish everybody was using it, especially when writing shareable code. So, we need people like you to support mdotting, not discourage it.
>>
>
>>Please take the time to think about you just wrote....
>>What you really are saying is that your way of coding is more susceptible to naming conflicts because of using code from others. You are relying on others to make sure the conflict does not occur.
>>Would you now agree that if this is a problem you have to have a second line of defense to make sure variables and fieldnames are not the same? After all it is easier to control a database structure than it is to control how code is written by a dozen of developers.
>
>The only and most convenient way to make sure that variable and field names are not the same is to mdot your variables. Your convention for field names alone gives you no protection.

In combination with the naming convention on the variables, yes it does.

>One of the other dozen developers could very possibly name variables that match one or more of your conventional field names. That's something you have no control over, and that is why developers sharing their code should write it responsibly. Your schema does nothing to protect against running 3rd party code that has a variable named ord_code, for example. Give me the list of fields, and I'll give you the list of possible conflicts. You gotta have both a convention for naming fields, and a convention for naming variables. And/or use mdot, as should everyone else.

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.

>>And there are lots with great reputation who do not.

>Nowadays, they should, especially if they share their code.

Reality is different, check the source code available on VFPx and you'll see... Most programmers, even seasoned have problems in applying the rules for mdot in a consistent and safe way.
The theory and reality are two different things here.

>>>>Not applying it consistently only adds to the risks to forget to do it where needed. And if you need a very lengthy wiki topic on fox.wikis.com on where to apply it and where not, it is a good indication that you're waiting for mistakes and a false sense of safety. Hence my objection against that practice. Again look at the source code available on VFPX and the rest of the internet. You'll be surprised.
>
>>Relying on mdot (alone) to avoid the conflict is (by far) not enough. Programmers are sloppy by definition and therefore one SHOULD avoid the risk of the var/field conflict by means of naming them differently so that no confusion could exist. You and I know that when not doing that, forgetting one mdot would lead the boat to sink anyways. That risk is far greater if deliberately using the same naming for fields and variables, feeling protected by mdot.
>>using mdot gives programmers a false sense of safety avoiding the issue, while every one can check for themselves that the reality is that most programmers are either not consistent or sloppy and forget to apply it where needed. Again the reference to VFPX is in place here as it would not take you long to find examples of the above.
>>Lastly. Please take a look at http://fox.wikis.com/wc.dll?Wiki~EssentialMDot~WIN_COM_API and the discussion there and really (if you can) try to ask yourself what a new programmer would think about reading this all? mdot is sorry piece of band-aid for a problem that should never existed in the language in the first place.

>False sense of safety? I have a problem with that argument. So, what you're saying is that because there might be a programmer out there writing sloppy code, I should not adhere to my conventions because it's all gonna end up in hell anyway :) Really?
>Show me something in the wiki discussion that proves you should not use mdot.

VFPx is packed with tools and source code. If you find it is scattered with examples of mdot either not applied or inconsistent manner and full of forgotten mdots, you really need to wonder yourself what the hell are we trying to fix here.
The only problem that needs to be prevented is the fieldname and variable name classes.

It absolutely a bad idea to rely on mdot to prevent this problem as I can show you many examples where people have not applied mdot in a way that it will eliminate the problem enterely.
The first line of defense is to make sure that your variables and field names follow a different naming convention. If you do that you have much less risk to run in this problem that entirely relying on mdot.

>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.

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.
Sorry but I got bigger worries than to adhere to a standard thrown up by some who think they have seen the light. It simply is not an issue. 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 are producing the same quality level of code and make sure they are using the same naming conventions.

>So far, the only false sense of safety that I see is in the belief that one's conventions (lacking mdot) are enough to protect against the risk of var/field/cursor name conflicts.

That is your opinion, and a very weak one if you ask me. Look around you, the reality of coding practices out there tell a total different story: the usage of mdot is a mess. And I don't see that changing any more. 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)


>I don't think there's much more to be said, since this has been rehashed several times before. Hopefully, someone will learn something from this discussion, too.

I hope so too, that common sense is to prevail.