>>>>>When I write the code I will never have the problem of using the m.dot or not using the m.dot. My coding convention uses the above rules. However, when we use classes that the community has written now we could have potential naming conflicts between variables and fields. So having the compiler enforce the rules is preferable.
>>>>>
>>>>
>>>>Just want to point out that the Hungarian naming convention isn't infallible. While it's a bit of a stretch, it's certainly possible to have a field name lOrange and a variable named loRange. I haven't gone hunting for other examples, since one makes the point, but I'll bet there are others that are plausible.
>>>>
>>>>In my view, VFP developers should always use mdot where there's any chance of ambiguity. That's even more important for tool writers since they have no control over the naming of fields in tables their users create.
>>>>
>>>>Tamar
>>>
>>>To avoid ambiguitiy as much as possible I tend to use objects instead of simple variables. An object with the same name as a field can be used without m. as long as you reference any of the object members. It also provides you a level for extension methods that can be very useful in daily coding life.
>>>

>>>CREATE TABLE Test (loTest C(10))
>>>INSERT INTO Test Values ("Field")
>>>LOCAL loTest AS Label
>>>loTest = NEWOBJECT("Label")
>>>loTest.Caption = "Label text"
>>>MESSAGEBOX(loTest)
>>>MESSAGEBOX(loTest.Caption)
>>>

>>>Therefore I use classes for repetitive work like for counters or strings:
>>>

>>>* Instead of 
>>>LOCAL lnCounter
>>>lnCounter = 0
>>>lnCounter = lnCounter + 1
>>>Messagebox(TRANSFORM(lnCounter))
>>>* it is better to do
>>>LOCAL loCounter AS Counter OF Utils.vcx
>>>loCounter = NEWOBJECT("Counter","Utils.vcx")
>>>loCounter.DoAdd()
>>>Messagebox(loCounter.Value_toString)
>>>

>>>
>>
>>I would do Messagebox(m.loCounter.Value_toString). That would eliminate any risk of conflict with a table alias/fieldname locounter.value_tostring.
>>*
>
>That is the point where I disagree. If you had an alias that is called loCounter, that alias is known throughout the workarea. That means any code that is called within this workarea can refer to the alias loCounter. It is similar to a public variable. That means the same conflict you can have with the variable name loCounter, you can also have with another table alias that you also like to call loCounter, except that would generate an error on the USE command.
>For that very reason I started to use Guids as aliasnames and encapsulate the cursor in an object.

Careful! You have to write code so the compiler is not confused before you ever consider what another programmer "understands". I know of people who think they deeply understand mdot, but don't fully apply it properly.

FoxPro is looking at the environment. When you write loCounter.Value_toString FoxPro will first look for the alias, and if found, will then look for the field called Value_toString. If the alias is not found it will then look for a memory variable. So, since you're trying to not confuse the compiler, and only in the later versions of VFP - you would do well to ensure the compiler knows that loCounter is actually a memvar and not an alias. Don't forget computers are actually not intelligent.