Hi Elmer,

>1. Using Mdot immediately makes code more readable, especially to a someone who doesn't have intimate knowledge about the design and logic of the code, programmer's style and naming conventions. It immediately identifies that the referenced variable is indeed a variable and not a field, thereby removing ambiguity in the readers mind without having to look any further than the current line itself.

My point on this is that readability is a personal factor. what one regards as readable, another will find not readable. It is just part of personal preferences. Personally I find using mdot making code less readable, but I'm fully aware that its 'personal' and that many others would totally disagree with this statement.

>2. Whether you use naming conventions or not, VFP by design considers all variables that are not prefixed with Mdot as ambiguous references that must be resolved at runtime. It has to perform a lookup in the list of fields in the current workarea for every variable that is not prefixed with Mdot. Unless I am not understanding how VFP internally handles this ambiguity, using Mdot immediately identifies it as a variable and effectively short circuits the resolution process, bypassing the field list altogether. That should provide a performance boost, especially when many variables are referenced and the current workarea has many fields. An added benefit is that it eliminates any potential future bug should someone ever add a field with the same name.

I know about every detail about the technical aspect of mdot, but it is just not an issue I regard of any significance. The performance boost is inmeasurable in all except very specific cases. Even then the performance difference is marginal.

>While a perfomance hit may be negligible in most cases, not using Mdot, IMHO, is much like programming a DO CASE structure where the most often occuring CASE is the last CASE or OTHERWISE section of the structure, causing each condition to be evaluated every time.

Also in this case, performance is not the factor that determines the place of a CASE statement in a DO CASE. The performance differences is in most cases negligible. Personally I use the order of the CASE to rule out certain conditions. I take advantage of the CASE ordering. While not regarded as best practise by many, its a practise I'm very comfortable with.

I want to take the opportunity to point out, that seeking performance improvements in this kind of issues is useless. Most of the time the performance issue is related to database access or the algorithm or design of the system. Focusing on these kind of things to improve performance is non productive IMO.

>Just my $0.02

My € 0.02

Walter,