Hi cetin,

Personally I find the three letter prefix very practical, because this way you can make essentially every field in the database unique. Not only practical in joins in SQL-SELECT statement (You don't have to use an alias prefix), but also in SQL Views: You don't have to wonder where the field came from.

As for variable name. I don't care about the scope prefix. I do use however a c,d,l,n prefix just to identify its type. Not particular neccesary, but just a personal preference.

I'm not using m. because of my personal preference that it disturbs reading. I find it ugly looking. And if it does not have any significant purpose to you and don't like it, why use it?

Walter,



>>Hi Fabio,
>>
>>>

>>>? varCash
>>>

>>
>>Whether or not to use m. is not a rule but a personal preference.
>>I've got other rules to make it clear whether it is a field or variable:
>>
>>Variable:
>>Prefixed with a type character (eg: cString, nCount, lUsed, dDate)
>>
>>Field:
>>Prefixed with three characters identifying the table (eg: prs_pk, Prs_firstname, prs_lastname)
>>
>>IOW, In my programs there is no question whether we talk about a field or variable.
>>
>>>

>>>correctness and formal precision
>>>

>>
>>I've got trouble with this as there are quite a few arbitrary rules when to use or not to use m. Those who apply m. themselves have different rules where and when to apply them as wel. Some say it is not neccesary at a variable assignment while other say you must be consistent and apply them where you can. It does not make sense to me. I just don't use them unless neccesary for whatever reason.
>>
>>Walter,
>
>Walter,
>Personal preference. I was very angry with a project I took over for it used that 3 letter table prefix for each field (it was not yours:). I personally hate somewhat Hungarian notation either:)
>A FirstName is a FirstName self describing its base datatype as a string and Date, DateOfPurchase are self describing their datatype as date (dDate for me is acceptable just to prevent it being a reserved word). I wouldn't expect to see cDate, tDate etc. anywhere at all. If there might be any ambiguity in variable name then a prefix would be OK.
>When it's prs_FirstName you still explicitly alias it in almost anywhere in code as Personnel.prs_FirstName, right? If so why not simply alias memory variables too. m is short and slick and you can't have an alias for a table/cursor as 'm'.
>As per performance when it's in an extreme loop you're gifted with a great timing. When not what you lose for using m. is simply negligible.
>In my codes you might frequently see lcFirstName and it's just a bad habit I got since visiting UT in 96:) c is redundant there, l (L) is something I like as a reminder of scope.
>Anyway commenting on what's mainly is a personal preference (yes I accept it's not mandatory and could be controlled by other means) somewhat meaningless. Added my points for benefits (or lose) of the newbies. Newbies unfortunately doesn't tend to use at least one set of concrete rules (and yes I was a newbie one time doing that too-got my lessons:).
>Cetin