I have been reading this thread and thought it was interesting that this is the first I have read about Hungarian notation. It has been my experience that I have had may more problems changing the type of a variable then a conflict between variable and a field. As far as readability, I like to know how my variables are scoped as I am going through the code. It is vary easy to see that lcvar is a local variable that is a char. The only time I use a M.var is when I am setting up to insert a row.

>Hi Mike,
>
>In message id 6418030 Cetin says:
>"If you don't include m. in for loops VFP7 is slower than previous versions (documented somewhere)."
>Do you know anything about this?
>
>If I understand you correctly, you advocate using m. whenever VFP MIGHT get confused about whether to use a field or memory variable, otherwise don't use it.
>Is that correct?
>
>Up until now I've just relied on hungarian notation along with a field naming convention to keep things separated, but your point about somebody else inheriting my code does cause me to reconsider.
>
>But mostly I'm just interested in the performance issue that Cetin mentioned.
>
>
>
>>Hi Bill
>>
>>This is one of my pet topics ;). I believe its important to really understand the code we write.
>>
>>m. Rule: If when checking variable contents and there is a field that matches the variables name in the current alias, m. tells VFP to look for the memory variable instead of the field name.
>>
>>Look at these lines of code...
>>
>>lcVar1 = 1
>>store 1 to lcVar
>>m.lcVar1 = 1
>>store 1 to m.lcVar
>>lcVar2 = m.lcVar1
>>if m.lcVar1 = m.lcVar2
>> ?"Hello"
>>endif
>>
>>Line 1 is clearly a variable assignment. The m. is not necessary.
>>Line 2 is clearly a variable assignment. The m. is not necessary.
>>Line 3 is perhaps easier to read, but the m. is redundant.
>>Line 4 is also easy to read, but redundant.
>>Line 5 is best written this way. Its perfect according to the above rule.
>>Line 6 is also best written this way, for the same reason as Line 5. Memory variables are being checked (not assigned) on both sides of the equal sign.
>>
>>I wish VFP would give a syntax error on Lines 3 and 4. Then, everyone would know about this issue.
>>
>>Hungarian notation proponents will argue its unlikely that a field name will match the variable name, but the point is, if it should ever happen, the code will break! Imagine how long it'll take to debug. That'd be learning about this the hard way eh? I explained this to an associate just recently, and he didn't know it. He hadn't been bitten by it, but that's just luck.
>>
>>BTW, should a programmer inherit your code and add a field to a table, breaking the code, you'll be blamed <g>.
>>
>>As for performance I just ran this...
>>
>>a=SECONDS()
>>FOR lnI = 1 TO 500000
>> a1 = 1
>>ENDFOR
>>?SECONDS()-a
>>
>>resulted in .360 seconds
>>
>>a=SECONDS()
>>FOR lnI = 1 TO 500000
>> m.a1 = 1
>>ENDFOR
>>?SECONDS()-a
>>
>>resulted in .362 seconds
>>
>>VFP7 with a P3650
>>
>>
>>>I just saw a message on another thread (message id 646222) that made reference to using m. for performance issues in VFP7.
>>>
>>>What's that all about?
>>>
>>>TIA