>I have full controll over each single line, no external frameworks etc.
>
>I only like to point out that I hate such 100% expressions. There are always two sides of it.
>
>If it would be mandatory the lang need to contol it. If it is free then its my problem, as long as the manager doesn't care.

It's not mandatory, so we're talking of best practices, i.e. different ways to do things and the merits and downsides of each.

There's a paper or blog by Calvin Hsia about how VFP parses names of what can be a variable or a field. Since syntactically they don't have to differ, i.e. you can say x=var1+fld2, VFP has to find out how to handle each one of them. Since the fields from the local alias take precedence, it's parsed first, then the variables. Now if you're in a tight loop and your current alias has 250+ fields, m. will tell Fox "this is a variable", and it will happily skip the check in the current alias, saving you cycles.

Most of the time this doesn't matter, you know that your fields have names which can never be the same as any variable names, because you have a foolproof naming convention. But Fox doesn't know this, and will check the current alias all the same, unless you supply the mdot.

Specially if you write a component for others to use, or are a part of a larger team, when you don't know their naming convention (or have a newbie on the team who doesn't yet follow it quite), you risk accidentally having a variable named exactly as a field in the current alias (which may not have the proper prefix if it's a denormalized cursor for export into a csv and you want readable column names; other situations are possible). Mdot saves the day in such situations.

I'm guilty of neglecting such situations, and I have been bitten - this kind of bug is damn (pardon my religion related intrusion here) hard to catch. You just see that your variable is assigned a proper value, but its value remains something unrelated - because you (and Fox) see the field value. Takes a hour or two.