Mike,
>>When it comes to personal preferences, WE ARE ALL STUBBORN.
>We should be open minded and willing to change. I changed from not using m. to using it. I even changed from trying to use it only as required to using it as much as possible.
If the arguments are really about technical issues we all should do it consistently and use the FabioL approach. I remember the reactions on the code of fabio using m.THISFORM, m.Object, m.THIS. But when you really dig into this, you'll see that the current approach of most VFP developper does not make sense at all (Refer to the wiki topic). It is highly inconsistent in the sence that it aid only technical issue and does not say anything about programming clear code. IMO, it is utterly stupid to use it or not depending on the technical argument that it might or not might be confused by fieldnames. Much better is to use it consistently, or not at all. The currently advocated approach is highly confusing, even for experienced developpers and highers the risk of not solving the problems it pretents to solve.
EXAMPLE: Show the following to a non-VFP developer and try to explain why you use m. or no m. in certain cases.
nCount = m.Count + 1
m.Command = "SELECT * FROM MyTable INTO CURSOR THISFORM"
&cCommand
nProperty = THISFORM.MyProperty
The speed issue is IMO not relevant at all here. Though it is good to know that it makes some difference in very exceptional (productional) cases, it by all means should not be part of decision to use it or not as your coding standard.
As for the argument of beeing open minded: Yes, I'm open minded. If I'm going to change (however in my current projects I don't see any reason to do so), I'd better change to FabioL's method to use it everywhere an memory variable or object is reference. That is consistent.
>Subjective arguments that it makes the code ugly are not logical. The appearance of the code is not a big concern.
Ehhh.. The apparance of the code is of BIG concern. The code should be as much readable as possible. For someone it might mean that code without m. is more readable than for others. Personally I hate the m. as it takes up space and burderns MY readability. In so far the the concern is for a high degree personal.
>I've worked with many different people and don't care how the code looks. Objectively mdot makes things safer and a little faster in VFP. Good enough for me.
I'm glad it is good enough for you. Using m. or not is part of the naming convention discussion. This is an area where no-one will get an agreement with everyone. You are fighting a battle you cannot win. I remember a statment from you saying something like "I'd prefer freedom over fasism anytime". I'd like you to review your standpoint on this issue again and see where that places you in this context. It all has to do with adaptation. Beeing able to switch to use what you need in a certain project. If I'm involved in a project using m. then I'll use m., If not I'll not either. Trying to convince others on the ground of technical issues that do not apply OTOH is a prove of beeing STUBBORN rather than beeing persistent.
Mike, I respect your preference for you usage of m. and you evangelism to use it. OTOH, you'll have to respect others who have another viewpoint on this. AFAIK, we both know exactly the technical consequences of the usage or ommitance of m., but we have different solutions surrounding the issue. And this does not only apply to me, but also to a lot of highly respected people arround this forum that have work with an awfull lot of people, more people than either you or me have worked with.
Walter,
