>Hi George,
>
>I respect your opinions, but please don't mind I express my different views.
>
>>I haven't ever experienced a crash because of the mdot issue.
>
>It is because you do not use field names like TcTable, PcItem, LcDesc, TcOrder, etc (all of them are variables, without m., found in xSource). I won't be surprised if such names are found in other programmers tables, particularly those migrated from FPD and FPW (in which field width are limited to 10 characters)
>
>TC, LC, PC, GC, LN, and so on, are good candidates for describing business items. For example, somebody may define a field LcDesc for Letter of "description for letter of credit", a PcItem field for "component items of personal computer", and a TcOrder field for "sorting order of table of contents"
>
>The most serious thing is that the name crashes do not necessarily lead to obvious problems. Issues may be hidden until users complain or tragedies emerge. For example, the following code (found in RI Builder) may run without any problem in development even if a TcOrder field does exist, but lead to wrong result in the future.
>

>IF NOT EMPTY(tcOrder)
>	...
>ENDIF
>

>
>>If you don't like the way the code is written, then, in most cases, you have the source, so change it. I have.
>
>VFP are used by a large number of programmers of various levels. For programmers of elementary and average levels, they may not be aware of the issues. Even if problems are encountered, they may not know the reason or how to solve them. Anyway, it is not a simple job to add "m." back to the variables in the sources and rebuild the tools.
>
>>What we're talking about here are tools that are provided, free of charge, with VFP.
>
>Actually they are integral parts of VFP, which are necessary for our development work. They are different from other free public domain tools which claim "They are provided in an 'as is' basis. Use them at your own risk."
>
>
Ben,

Please allow me to answer all three of your responses here.

First, regarding the performance issue. I'm glad we're in agreement.

Second, regarding the use of the word "indefensible", let's say your English is a lot better than my Chinese. I tend to forget that when someone, such as yourself, expresses themselves so well, that it's not your native language. Please forgive me.

Lastly, in this case, I think what you're seeing in the tools is the use of Hungarian notation. Now, we could debate whether or not it's appropriate when naming fields. For myself, I don't think it is.

The purpose of any convention is to make the code more readable. To this end, when naming a field, I don't use Hungarian notation. I try to make the field name reflect what the data is rather than the data type.

For example, if the data type is an integer, and the data is something like pounds (English weight), then I'll name the field "Pounds" rather than "iPounds".

In your example, "tcOrder" tells me that it's a character string passed as a parameter. I see nothing wrong with the naming convention. However, if it were a field in a table, what would that tell me? Is it a datetime represented as a character string?

This is just my opinion. Each of us has our own personal perferences and conventions.

Regards,