Re: Hungarian Notation


> Again you seem to assume (by trying to get an "admission" out of me)
> that I had to "rein myself in" and "resist" going overboard.

Not really. The point I'm trying to get you to see is that clearly at some point HN gets unmanageable. And for exactly the same reasons that it gets unmanageable it is always somewhat more difficult to read - there is a scale of difficulty from not very to damn near impossible.

Presumably you get some perceived value from using HN (although I still don't know what it is - see below) that makes it worth your while doing that. You don't use very many abbreviations, so your code is presumably not that hard to understand. Fine - but missing my point still.

HN *is* harder to read for most people, as I have maintained all along. Just because *your* version is not particularly difficult is not an argument against my point.

Abbreviations are almost always harder to understand than the word or words that they are abbreviating (some exceptions, as you pointed out, to which I would add some units of measurement). If you look at the design guidelines for critical instruments and systems that people might use in high pressure situations - not many abbreviations are allowed. And in the programming world, very few abbreviations are standard. Nobody outside of New Zealand thinks they have a btn on a form, they think they have a button. Why not say so?

Also abbreviations are fragile to inconsistencies. "CustomerCombo" and "CustomerComboBox" in the same code is better than "cbCustomer" and "cmbCustomer" in the same code. Or worse, "CustomerEditBox" and "CustomerTextBox" vs "edCustomer" and "tbCustomer".

Just by using abbreviations, you automatically make your code somewhat more difficult to read. But HN also reverses the normal order of things (in principle you could use "CustomerBtn" instead of "btnCustomer"), and changing the normal word order for a language makes it harder to understand too (assuming English - I presume this is not always the case in other languages).

There is no argument that HN is harder to read (except maybe for some very unusual people for whom abbreviations are not harder - hence my "most people"). There is only an argument about what value you get from it, and whether that offsets the extra difficulty. By not having a very complex form of HN, you need to get less benefit to make it worthwhile.

Now, while I would regard any perceived benefit as highly dubious, I would not claim that you do not get any. I think the people arguing with me do not see the distinction. I probably haven't helped because I have been covering both things in the same replies, and since I am attacking a holy cow, the finer details are lost in the frenzy :-)

I use the prefixes I do in a similar way; to indicate more essential types

Yes, I understand what you're trying do with your names (I always have and I do pretty much the same thing with my names), but that isn't what I was asking. I want to know why you use "btnSomething" instead of "SomethingButton".

It seems somewhat inconsistent, since you do not do the same thing with anything else, for various reasons. Why are components special? I'm asking you what your perceived benefit is.

> (This is as close to a victory as you are going to
get here, so live it up! <g>)

Well, I know I'm right about HN anyway :-) Hmmm, just got an idea for a little de-HN tool - I wonder if it would work in an patterns article, I've been looking for an example :-) And then if I built it into a virus ,...hmmmm.

I wasn't trying to get you to change the way you choose your names, BTW. That is a separate thing from formatting the name using an HN scheme.


Cheers,
Jim Cooper

__________________________________________

Jim Cooper    jcooper@xxxxxxxxxxxxx
Tabdee Ltd    http://www.tabdee.ltd.uk

TurboSync - Connecting Delphi to your Palm
__________________________________________
.