Hi Mike,

>>BTW, I did test this in a 1 million iterations in VFP8 and could not get any noticable difference.

>The fact is there is a performance difference and it is always a gain, never a loss. Small performance gains are better than no performance gain. But the performacce gain is a side effect of not relying only on naming conventions to avoid the conflict.

In fact when I run my test several times (using m. when assigning) I could not tell the difference. Sometimes without was faster sometimes with was faster). IOW I cannot confirm your observation that it is faster.

>Take a look at the GENXTAB.PRG code that ships with VFP. Look at GenMenuX.PRG. You will find examples of mdots that violate the "rule". They were aware of the potential and tried to code for it!

It's just a pitty they did not make this a standard in the first place.

>Most people are just not aware of the problem until it bites them. Even the source of VFP doesn't get it right. Maybe they don't even learn anything from the bite. Maybe they just change the field name to something else, and when the problem goes away, they say "VFP is stupid".

You can't anticipate on that. There are too many issues on which they can draw that conclusion.

>I've seen the conflict appear many times. As you say, naming conventions reduce the incidence, but it doesn't eliminate the problem.

>Even you were surprised there was *any* difference related to the number of fields in the current alias. Please at least agree that the "negligible difference" is always a net gain.

I agree, but you know my standpoint that it insignificantly small to be a factor in the discussion whether or not to use mdot. You're making a claim that it does. This is what I find misleading, raising expectations that do not come true. No VFP developer should troubleshoot their performance problem by using m.. If you say you should, I'd think you've got the wrong idea about what generally causes performance problems.

>>About your rule, I think the wiki reference you gave still mentions exceptions to this rule, where VFP does not let you do this.
>
>Except for the macro substitution, I think the rule applies.

And about passing variable by reference ?

>>However when talking about something abstract like a coding standards personal preferences come into play. We should all accept that we've got different coding preferences. But maybe a code standard could just describe two or more variations on a subject like naming variables. Just as long as its used consistently I don't have problem with it at all.

>Ahhhh! So we really don't even agree that this is a coding convention issue versus an actual problem solving performance enhancing technique!!!!

I don't agree in the performance enhancing technique: It's too insignificant IMO. It is not a problem solving technique either, but rather a technique to prevent a specific problem.

There is also another technique to prevent the problem: Just be sure you don't have a conlfict between field and variable names.

>I certainly do not see it as a simple matter of personal preference. A penny saved is a penny earned.

In this case you're not talking about pennies but of something far less than that.

>So, if we were to suggest a standard, it would be use the mdots everytime you refer to a variable. I can live with that.

No problem with me either. Not that I'll use this particular part of the standard anyway's but I can live with that....

Walter,