>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.

That is your opinion and the fact is anyone can get used to seeing them. Therefore mdot is only affecting your perception of readability. In fact it does not affect 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.

That is your limited world. I deal with other people's code all the time. They do not have naming conventions. They don't know of the mdot issue.

>
>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.

Agreed.

>
>
>>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.

You are misinterpreting what I said. I only said don't smoke while pumping gas. Your argument about readability is cosmetic, not technical.


>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.

Well, that's why we're disagreeing. Your experience is with code that has no problems with mdots. I get emails and see posts where the problem with the piece of code is the lack of mdots regularly. Those pieces of code are either brand new code or code that suddenly failed because it was put in a different environment or given a new table with field names that conflicted. The problem does exist, the risk is real except in your limited experience.

>
>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.

Then you will only be arguing against the other's opinion and not respecting their right to make that opinion. Your experience shows there's no problem, that means you do not have experience with the issue, so why make an statement?