>>I didn't see where GarrettF 'recommended' naming conventions, but then the words end with a "..." and I couldn't find how to read any words that might be beyond that.
>
>The title of his entry is "The dangers of not using naming conventions." Doesn't that imply he feels the fix is to use naming conventions?

I guess it does... at least two see it that way, and I'm the odd man out < s >



>
>>
>>On the other hand, to me naming any data field as "X" is silliness in the extreme and should never be done except to demonstrate possible problems like this. I wouldn't call that a "naming convention", but rather just common sense.
>>
>>I believe that m. should always be used where there is jeopardy of conflict with field names, naming standards or no naming standards, for self-consumption or for publication.
>>
>>
>>
>>>I hope Garrett Fitzgerald won't mind I quote his blog here:
>>>http://blog.donnael.com/2006/02/dangers-of-not-using-naming.html
>>>
>>>I don't agree that applying a naming convention is the proper solution to the issue reported in the blog. The issue should be addressed by applying the "m." prefix.
>>>
>>>Garrett, a VFP expert, spent 15 minutes in finding the problem. Imagine an average (or below) VFP programmer gets unexpected problem when he runs the VFP RI Builder. He may never know the problem is caused by a name conflict between his table field "TcNewValue" and the variable "tcNewValue" of the VFP RI Builder.
>>>
>>>My opinion:
>>> When we are coding for our own project, "m." is not necessary.
>>> If the code is going to work with others' (clients or public users) tables or codes, the "m." prefix is necessary.
>>>
>>>I hope the xBASE (VFP) code of Sedna won't have similar traps (if we don't call it bugs).
>>>
>>>Ben