Mike,

>>If the arguments are really about technical issues we all should do it consistently and use the FabioL approach. I remember the reactions on the code of fabio using m.THISFORM, m.Object, m.THIS. But when you really dig into this, you'll see that the current approach of most VFP developper does not make sense at all (Refer to the wiki topic). It is highly inconsistent in the sence that it aid only technical issue and does not say anything about programming clear code. IMO, it is utterly stupid to use it or not depending on the technical argument that it might or not might be confused by fieldnames. Much better is to use it consistently, or not at all. The currently advocated approach is highly confusing, even for experienced developpers and highers the risk of not solving the problems it pretents to solve.

>You misunderstand. The wiki topic is attempting to show how to use m. at a minimum. It is not advocating that it be used at a minimum. I currently prefer to use it all the time. Now, THIS, THISFORM are "reserved words", so I can see the need to avoid them.

OK, I've missed that. However what to do if you've inherited a database that has a keyword a a tablename? You can avoid the issue with m. You'd better do it strict or not at all. If you want to prevent confusion, then you MUST apply it to keywords like THIS and THISFORM as well (Note, they are other keywords as well that might add confusion)

>>I'm glad it is good enough for you. Using m. or not is part of the naming convention discussion. This is an area where no-one will get an agreement with everyone. You are fighting a battle you cannot win. I remember a statment from you saying something like "I'd prefer freedom over fasism anytime". I'd like you to review your standpoint on this issue again and see where that places you in this context. It all has to do with adaptation. Beeing able to switch to use what you need in a certain project. If I'm involved in a project using m. then I'll use m., If not I'll not either. Trying to convince others on the ground of technical issues that do not apply OTOH is a prove of beeing STUBBORN rather than beeing persistent.

>You think they don't apply. You've never had to struggle to figure out why a piece of code failed only to find it was because of failing to use mdot.

In fact, I'd indeed have a hard time remember one case in 10 years time of having this issue, yes. I typically do not work on existing databases. The problem is avoided to have a strict naming convention for variables and/or fieldnames. In my view the whole problem is more an academical one that one that should occur in practise if you've got a strategy to avoid it.

>I'm not choosing to use m. from personal preference. There are technical reasons for using it. Your reasons against it merely personal preference, based on the look of the code. Mdot does not affect the readability so that you cannot get used to it. There are other far more significant issues that affect readability of the code. Most people don't know of the issue. Many do and are starting to use mdot.

Mike, I don't see much significance in the technical reasons you name:
1. Avoid confusion between memory variables and fieldnames
2. Significant performance difference in exceptional cases.

In my case, case 1 is accomplished in a different way, by using different naming conventions for fieldnames and variables.

Case2 IMO is a bizar one as the circumstances of performance disadvantages not using m. are so rare that no-one should use this as an argument at all.

>I strongly believe the insignificant inconvenience of the look of the code is far outweighed by preventing code from crashing because of human error with field and variable naming.

I strongly believe that the personal preference of coding makes a huge difference to your own code readability. It is MY preference not to use them. I'am not sensible of the argument of crashing code at all because.

1. My experience tells me I rarely encountered one (I cannot remember If I ever did in a delivered product).
2. Even if I encountered one, it most likely will be tracked in the debugging process. Every code has to be tested anyways.

Again, IMO, you're fighting an acedemical issue that has little value/application in real life in most cases.

Walter,