>>Naming conventions are *not* helping us to read the code. I've never felt that naming convention helped me in any way.
>
>Well, your experiences with this are in diametric opposition to mine. In another message I saw one of your examples (ldInvDte) where you don't give the variable a descriptive name when using the naming convention. Naming conventions and descriptive names are not mutually exclusive. FWIW, I'd probably use ldInvoice in that case. Inv is ambiguous (ie, could be "Inventory" or "Invoice" or perhaps something else), and the Dte is redundant when you have a type designator.

There's a bit of a contradiction in your statement, Del.
First you say that "Naming conventions and descriptive names are not mutually exclusive", then you go and say "...and the Dte is redundant when you have a type designator". What's wrong with "InventoryDate" or "InvoiceDate"?

I think the major thing in all of this is that prior to VFP we were limited to 10 characters for variable names, field names, etc. While "Hungarian" forced the loss of 1 or 2 (depending on how a person practised 'safe' Hungarian) it also helped because it assured differentiation.

The article that started this thread says that MS (except the Word division) MIS-APPROPRIATED "Hungarian" and that things got so bad that they declared, for .NET, that the use of "Hungarian" was discouraged. I don't see how it could get any clearer than that.

Sure, people have gotten comfortable with the mis-applied "Hungarian". But it doesn't always work (if you use "txt" as "Hungarian" for a Textbox you still don't know what's inside it, for example), so you don't really have a "standard" anyway.

This is another of those near-religious issues in programming. It doesn't make my religion better than your just because I don't use it and you do.
But I must say I am happy to note that MS saw the error of their ways < s>



>
>>Whether or not using naming conventions, I still should know when, why and what a variable could/should contain. You can't tell this story with naming conventions.
>
>Ideally, that (knowing when, what, why) should be the case, but pragmatically, it is not. I doubt anyone has ever said that a naming convention tells the whole story. Rather, it tells you enough to save you some time here and there. Naming conventions clearly add value for alot of programmers, otherwise they would not be so widely used. I'll agree they may not be quite as effective if you're not using descriptive names as well.