>>>>>Totally agree.
>>>>
>>>>Acknowledging that all this does come down to personal preference, choosing to not use "m.", for whatever reason, is similar to being so confident that your own revolver is not loaded that you happily put the barrel to your temple and pull the trigger 6 times.
>>>
>>>I say, Jim, steady on! I've never used m. and never got outside a bullet for it. Am I wrong in saying xBase is the only language that uses this and all the others seem to get along OK without it?
>>>
>>>Cheers
>>>
>>>Terry
>>
>>The difference, as I'm sure you know, is that in VFP you can have fields and variables that may have the same name and can be referenced the same way in code. When that occurs, it causes an ambigous reference. Because VFP is a data-centric language, when a field exists with the same name as a variable, the VFP rule is that a field takes precedence over a memvar to resolve the ambiuous reference. The only way in code to differentiate a memvar from a field with the same name is to use m. An exception to this rule is when it is an assignment, because you "replace" a field and "assign a value" to a variable. When the program logic is expecting the value to come from the memvar, but the contents of the field is read instead, unpredictable errors can occur.
>>
>>When I write code, expecially reuseable functions and such, I don't always know who where it may be used and what tables may be open. Unless you use a variable naming convention that guarantees that you will NEVER have a field named the same as a variable, m. is your only defense.
>
>Thanks, Elmer. Like you said, as you're sure I know... As had been said, in this thread, the use of variable naming conventions ( e.g. lcCustName for CUSTOMER.CUSTNAME, lnUserID for USER.USERID, etc), which I strictly adhere to (except for using good-ole "I" for loops) would seem to obviate the need for such differentiation. Whatever, I've never (knowingly!!!!) been bitten. As someone else has said, always using the alias when referring to fields doesn't hurt, and further clarifies the situation. Some other languages you have to do this anyway.

Terry,

Yes, using alias.fieldname for fields does help make code more readable and other languages may require that, but it really does nothing to eliminate the possibility of ambiguous references to variables. Because of fields taking precedence over memvars, when you have a field in the current alias and a variable of the same name, when referencing the variable without the m., VFP WILL read the field instead of the variable. This is the "by design" behaviour even if every other place in code you reference the field as Alias.fieldname. This is a rule in VFP that you cannot change. You indicate that your naming convention prevents that possibility, but really there is nothing to prevent the off chance that somone using your code may have a table open in the current workarea that may have a field named lnUserID or any other memvar name thay you may have used.

I have been bitten by this several times when using code from others, so I tend to practice defensive programming and use m.variablename to reference variables and alias.fieldname for fields. If you have never been bitten, that is great, but for anyone lurking here, it might be a good thing to be aware of this fact and know that intermittent logic errors can occur caused by this behaviour. Errors like this can be very difficult to track down.