>>>m. means, that it's a variable, not a field name. Basically, it's not necessary to preceed variable name with m. However, you never know, how somebody can name fields in his/her table. Say, somebody needs a field called tcName (as it was quite recently in one of Jill's message). If you name your parameter tcName and use it without m. prefix, field name would take precedance. That's why couple of months ago I began to use m. prefix everythere in my programs. Before I didn't pay attention to such minor detail. Also I believe, that style of one of my colleagues made an influence on me. One of my colleagues, whos programming technique and style I respect most among other contractors, uses them everythere, where needed. I adopted this idea in my style.
>>>
>>
>>Just IMHO. Of course, it's a matter of personal style and preference.
>>On the other side, using m. it may be a sign of not effective enough naming convention for the variables and fields, or not following the naming convention. I personally use m. only in certain situations, for example when I use SCATTER and GATHER. or when I want to emphasize by some reason to whoever reads the program that it is a memory variable. Using m. everywhere, IMHO, is littering the programs with these "m." and is unnecessary.
>
>Nick,
>
>I agree, of course, that it might be personal. However, suppose, you create a class (:), which you then put to a public domain, and, say, you use lcFileName as a variable name everythere. Someone can have a field name LCFILENAME, where LC will have some particular meaning. And what would be result of this program? You can not tell. And the example I showed before with tcName is a real one, I saw a thread few months ago between Jill and Doug Henning, where this name causes problems. So, I better would be in a safer net...

Yes, that can happen and that is one of those special cases I am talking about. Also, if somebody has LCFILENAME he might as well have LCFILENAME variable somewhere. In this case non-generic and very specific variable names help avoid such situations. In case of public domain classes you might use non-standard prefixes to variables to avoid this.
But if you are working on your application with your chosen framework which you know everything about such situation should not happen if you follow the naming convention.