>>* a "better safe than sorry" measure -- no matter how careful you've been with design with naming of variables, tables and columns, once you start having "foreign" code or tables, you can't be sure conflicts can't happen.
>>
>>I think it is the opposite. Let me explain.
>>
>>In our database all fieldnames are unique because for each table we have a three character prefix + underscore.
>>The bonus is that wherever you see a fieldname you not only can identify its a field, but also the table where it came from.
>>It really is refreshing not having to use aliases in joins in SQL statements and really pays of in audit trails as well.
>>
>>For calculated fields we don't have the prefix, a name without any naming convention. For variables we use a variation of hungarian notation. Possible conflict between fields and variables are reduced to a minimum.
>>
>>Now the other side. I've already outlined the borderline cases with THIS, THISFORM and VFPs system variables.
>>But a more realistic problem is the following.
>>
>>When you are debugging a piece of code, and encounter something like the following
>>
>>

X = ALLTRIM(Zipcode)+" "+ALLTRIM(City)

>>
>>How the hell do you know whether the intention was to use a fieldname or variable if you're using the same naming convention? Suppose it needs to be
>>

X = ALLTRIM(m.Zipcode)+" "+ALLTRIM(m.City)

>>
>>How would you know without having to dig into the context of the code? With different naming conventions between variables and it would be.
>>
>>

X = ALLTRIM(Dem_Zipcode)+" "+ALLTRIM(Dem_City)

>>
>>vs
>>
>>

X = ALLTRIM(cZipcode)+" "+ALLTRIM(cCity)

>>
>>There is absolutely no question what the intention was.
>>
>>
>>Now let me give me some real world examples of where 3 party libraries got problems with mdot.
>>
>>The GDI+ libary. system.drawing.prg. One of the libraries which have applied mdot in the most consistent way.
>>
>>

>>			m.lhBitmap = This.GetHbitmap(CREATEOBJECT("xfcColor", ARGB_LightGray))
>>			m.lhBmp = CopyImage(lhBitmap, 0, 0, 0, 0)
>>			DeleteObject(lhBitmap)
>>

>>
>>ARGB_LightGray is a constant so has to be applied without mdot, but lhBitmap is not. It clearly is an error. Imagine you have a table open with a field lhbitmap. It would clearly would cause problems.
>>
>>Bottom line, my point is that mdot creates a false sense of safety.
>>just make sure the names cannot conflict and you don't have to worry.
>>
>>Walter,
>
>I get your point -- indeed blindly applying mdot is NOT a solution. In general blind adherence to any rule is generally not a good idea. As I implied earlier -- your rule of "just make sure the names cannot conflict and you don't have to worry" could end up falling apart once "foreign" code or tables are introduced. Also your rule often doesn't apply when you're dealing with code you may have inherited. The other point is that your examples also tend to be more "edge case" than the more common situation (i.e. I tend to think of calls to system API functions more of a "special case" situation). Perhaps Mike may be interpreting your argument as being a reason for abandoning mdot altogether?
>
>My first impression would be that an mdot probably should be added for the reference to "lnhBitmap" in the calls to CopyImage() and DeleteObject(). The mdot on the left-hand-side of the assignment is probably not needed.
>

>	m.lhBitmap = This.GetHbitmap(CREATEOBJECT("xfcColor", ARGB_LightGray))
>	m.lhBmp = CopyImage(m.lhBitmap, 0, 0, 0, 0)
>	DeleteObject(m.lhBitmap)
>

>
>I usually tend to not apply mdot on the left-hand-side of an assignment statement, and apply mdot on the right-hand side. I also try to make sure that whatever symbols that I'm applying aren't coming from a #DEFINE. [shrug] But this is sort of what you've got to live with with the way xBASE had evolved (i.e. it was meant to be a user application, not a software development tool).

Agreed. Oddly enough I worked at a place where Toronto's Jim Nelson once worked. While there I helped a co-worker who was crying. Her code ran all night and got the wrong results. When she explained what she wanted I fixed it for her and it ran in minutes. I then had to spend time teaching Jim Nelson and that team. So our harassing dickless wonder indirectly benefited from my training. When I finally got to see his code, it was laughable, so much that the people he showed it to laughed. I was way better than he then and am still. He can stand that. Poor thing.