>>>* where you use mdot often depends on context (which isn't always clear [for most people])
>>
>>???
>
>rephrased slightly: where need you use mdot to avoid ambiguity often depends on context (which isn't always clear [for most people]).
>You don't need to indiscriminately use mdot with every variable reference
>* it isn't required when it is target of an assignment statement (e.g. foo = value since foo can't be a field )
>* when variable is used within macro expansion (e.g. &foo -- due to the language syntax, foo is a variable)
>* and a few other cases
>
>what might be confusing (for some) is you shouldn't apply mdot everywhere indiscriminately, as there are cases you shouldn't use it:
>* e.g. if you try to use it in macro -- since dot portion would mean to expand variable "M" rather than being part of an mdot prefix
>* in the highly unlikely case where you're using WordTech's Quicksilver product (it's rather old, and only for DOS) -- if mdot prefix is used on left-hand-side of assignment statement, it created variable with mdot as part of the name.
>
>>>Although I agree with careful naming convention could be used to avoid variable/field/alias confusion (such application of convention is relatively easy), I don't agree that it makes mdot unnecessary. I (and others) have pointed out it often doesn't work if you have to deal with "foreign" code or tables (i.e. those from a different party). He makes the statement along the lines of "such code nor tables (that don't follow the naming convention) should never be accepted" -- I would counter that by saying that you don't always have a choice on the matter when you're tasked with interfacing with a "foreign" system. You may not always (typically never) have the luxury of imposing your style or conventions on the other system.
>>
>>Congrats, you're the first one to mention the inherited data structure. I was waiting for that argument to come and I would have expected that people would bring that up earlier. Yes, you are entirely right on the matter here. If you inherit a database over which you have no control and have assessed that there is a significant chance that you will run into a variable/fieldname clash, mdot is most likely the best route (assuming that your variable naming convention is not sufficient).
>
>Actually I'm not the first one -- several people did mention this before.

Correct. I said it several days ago. I mentioned that most of my work is with applications originally written by others, and thus I don't have the luxury of determining the naming conventions in use.

Side note: I've inherited a couple of applications in which all custom properties begin "r_" and all custom methods begin "m_". Pretty sure I know where that idea originated and I think it's an absolutely terrible convention.

Tamar