Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
The m. variable thing, the sequel
Message
From
29/12/2004 08:44:29
Walter Meester
HoogkarspelNetherlands
 
 
To
29/12/2004 08:08:39
Mike Yearwood
Toronto, Ontario, Canada
General information
Forum:
Visual FoxPro
Category:
Coding, syntax & commands
Environment versions
Database:
Visual FoxPro
Miscellaneous
Thread ID:
00969478
Message ID:
00972915
Views:
74
Hi Mike,

You're making a big thing out of something that is far too insignificant to most of us. And again to me the risk of writing bugs is greater when adopting m. because it hurts my readability.

In MY real world I seldom had to deal with the m. problem because the security is there. Tables are named with a three letter prefix and a underscore. Variables are type prefixed and are Camelcased without underscores.

This should be the first rule to avoid confusion between fieldnames and varaible names, not mdot because if the only protection between a variable and a fieldname is the dot, you're likely in more trouble than when having different naming conventions for fields and variables. If you then forget one dot the chances are far greater to have a problem, esspecially when not using mdot consistently everywhere a variable is referenced because it is hard to spot the problem.

The mdot should only be a secundary protection mechanism and not as the general thinking here the primary one.


>However, it is dangerous to smoke a cigarette while trying to pump gas into your car. Your concern about the readability of the code is like saying "I look cool with a cigarette". You are also saying "I'm careful with my cigarette" and "Nothing exploded yet, so I'm safe".

You're telling me something like: don't smoke ever if you have to fill your car with gas at some point. I'd say don't smoke when filling your car with gas. Your argument in here is, that if you accendently throw your sigaret out of your car while someone on the street is filling his car with gas you have a problem. Therefor conclusion: Don't smoke ever.

And of course the component of exaggeration: a Bug is a bug and can be fixed. There is nothing to fix if you blow up a gasstation.

>I will not be discussing this issue with you again, so please do me the same courtesy.

I respect you are using m. as I respect anyones choice here to choose it or not. You seem to have a problem in respecting my choice. That is your problem not mine. As I stated, many respected VFP developers do not use m., as well as many do use it, if you want to extract validity out of what you are trying to say.

I'm fully aware where a potential danger lies and what the implications are. It is just a small line in my big book of VFP programming rules. It is insignificant to the measure if you are a good or bad VFP developper and if a application is a well or bad written one. I really don't understand why you are so persistent in making such a big story out of something that insignificant.

I'll continue to reply on any statement anyone makes to force someones opinion through someone else his throat, esspecially when the arguments IMO are exaggerated, only personal preference or simply misleading.

Walter,
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform