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


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

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

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

>>>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.
*
Walter, the point here is that you should use mdot in addition to your conventions, not in place of.
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.
*
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.
*