Hi Walter,

I guess you see your own cantradiction?
2. some religions, say use it only when there can be confusion between variables and fiels
Number 2, IMO opinion is the most stupid one.
'and only in rare occasions where I cannot be sure of having a field name in a selected table, I´ll use the m. argument. '

Isn't the last line really what you describe under Number 2? I would say that number 2 is the BEST choice.



>Hi Fabio,
>
>>>Well, as Calvin has pointed out, if you prefix your memory accesses with m., pronounced "uhmm", things will happen faster. Seems contradictory, but uhm, who am I to say.
>>
>>Calvin say that to put m. prefix it is a faster option,
>>I say that who uses a memvar without a prefixed one of m. he makes a program error.
>>
>>The difference is substantial.
>
>Again, it seems a rather religious thing. M. does avoid VFPs confusion whether it references a field or memory variable and has an advantage over not using it when a table with large number of fields selected. Nothing new here. Calvins explanation of the internals are nice, but really add nothing news here.
>
>However,
>1. some religions, say never to use it, because it makes your code ugly.
>2. some religions, say use it only when there can be confusion between variables and fiels
>3. some religions, say always use it, even with objects, THISFORM, etc.
>
>Number 2, IMO opinion is the most stupid one. Heaving to learn a lot of rules when to use it or not (See wiki topic, often to do with VFPs internal behaviour) is nonproductive. It probably is more an idealism than anyone could possible stick to without making errors in this. Even though, people are trying to force this down our throat.
>
>Number 3, is an interesting one, you practise yourself. Trying to stick religiously to using m. and only omitting it in cases where you can´t use it (e.g. macros). I doubt if there are many people doing this so strict, but from a logical point of view, I must admit, you either do it, or not. It is not my personal preference though.
>
>Number 1, my favourate lets me keep writing code without the ugly use of m. and only in rare occasions where I cannot be sure of having a field name in a selected table, I´ll use the m. argument. As for the speed argument, it really only is applicable in long CPU intensive jobs where a large field count table is selected. I´d have difficulty in naming one case I´ve ever programmed in my carreer.
>
>Bottom line, you can write good and solid code with or without using m. . No matter the argument you´re not going to convince the well experienced VFP developper to change his standpoint on this. It is non productive.
>
>My 0.02 eurocents