Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
The m. variable thing, the sequel
Message
From
05/01/2005 17:30:36
 
 
To
05/01/2005 04:47:15
Walter Meester
HoogkarspelNetherlands
General information
Forum:
Visual FoxPro
Category:
Coding, syntax & commands
Environment versions
Database:
Visual FoxPro
Miscellaneous
Thread ID:
00969478
Message ID:
00974539
Views:
69
>My point is: Personally I don't see any reasons to use mdot in my projects unless there is absolute need to, because:
>
>- Collisions of fieldnames and variables are avoided.
>- It is my personal preference not too use it.
>
>And that is the bottom line. You can agree with it or not, but that is the way I've been doing it since I started using VFP.
>

PMFJI

Walter, I really have no desire to change your mind about using Mdot. Like you, I use naming conventions that avoid field/variable collisions. However, I also use Alias.fieldname and M.variablename for a couple of good reasons which make sense to me.

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.

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.

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.

Just my $0.02
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform