Arguments against Hungarian Notation

[Rob Wehrli]

On Sunday, May 05, 2002 5:52 PM, Kimbro Staken 
[SMTP:kstaken@xmldatabases.org] wrote:
>
> On Sunday, May 5, 2002, at 10:12 AM, Rob Wehrli wrote:
> >
> > Don't be a fool.  The VB programmers at Microsoft (and many other
> >
>
> Well wow, I'm so glad that I didn't get flamed or something. Nice, really 
> nice. Guess I should have stated that I've used both VB and hungarian
> notation.

Not meant to be a flame...don't read too much into it... :)  Having stated 
your VB and HN use would have at least made it sound like you weren't 
flaming VBers.  BTW...I didn't say that you were a fool, I simply cautioned 
you against being foolish... :)  ...and, why cut off your original 
statement in the reply?

    Hungarian came out of Microsoft from the C and C++ world, I suspect VB
    people just picked it up out of imitation without really understanding
    what it was for.

Just picked it up out of imitation (monkey-see, monkey-do) without really 
understanding (stupid or at least ignorant)...

I think that your statement makes my reply appropriate enough to use "Don't 
be a fool."  In effect, you're saying that VB programmers in droves will 
just follow like lemmings without knowing why they're doing it.  Not read 
too much into it?  How could one read less into it?  Oh...I get it, we're 
not supposed to read it at all, right? :)


>
> especially one that is really true. Very few people carefully consider 
the
> techniques that they use, this applies to VB programmers just as much as

I say, speak for yourself.  What statistical data do you offer to qualify 
your findings that "very few people carefully consider the techniques that 
they use?"  That is my "stupid monkeys" argument.  What makes you an 
authority on what people consider and what they do not.  Have you 
documented findings of your years of field research studying programmers 
and what they consider or are you simply tossing out your opinion as if it 
is fact?  Let me know if I'm "reading too much into it."

> it does to Java programmers or assembly language programmers. In reality
> all people on some level or in some activity simply follow rather then
> consider why something is done. Unfortunately, in the case of VB you have 

Jeepers...your "lemmings" case sounds so much like all of the ultra 
non-conformist programmers that I know...however, I guess "on some level" 
like, breathing regularly, we all "follow" without spending too much effort 
on considering why it is done... sorry, but the "don't be a fool" comment 
seems to imply, even though no flame is intended.


> a vendor in Microsoft who provides the leadership and everybody else is
> just going to follow. Sun of course does the same for Java.
>
> Hungarian notation was designed at a time when the programming model for
> DOS/Windows was even more complex then it is now. At the time the 
standard

What!?  HN came BEFORE DOS.  The earliest known data is that at around 1972 
Charles Simonya was using it.  This is taken from his account of it as 
given in a lecture in 1988, if I remember correctly.  I doubt that the 
"programming model" for DOS/Windows was "even more complex" before its 
existance, than it is now.

> windows programming language was C and not even C++ was really used and

Windows programming was...or PASCAL?

> Visual Basic was just a twinkle in Charles Cooper's eye. It was needed
> because you had a lot of variables, a lot of pointers and a really crappy 
> memory model that made you keep track of different types of pointers. In
> that environment it was very useful to know if something was a long
> pointer to a null terminated string or just a pointer to a byte buffer.

Finally, a worthy point!  FAR pointers... :)  We still have remnants of 
that legacy in Windoze code today!  However, if HN was useful ONLY for the 
"complexities" of managing various different pointer types, why then is it 
so popular in VB where there are no pointers?  Oh yeah, just the stupid 
monkeys following like lemmings...I keep forgetting how irreverently you 
quantify human intelligence, especially in technical fields where the 
average *must* be paradoxically and annoyingly rudimentary...to fit your 
descriptions, but, we really should not read that much out of it, huh?

>
> In a language like VB or Java you don't need this extra syntax. You have 
a

Your statement clearly states your argument as fact, while it is really 
just your argument.  You say that you don't need this "extra" syntax, then 
you go on to justify it.

> flat memory model and no pointers. You also make extensive use of
> components that encapsulate many things that would have otherwise been
> variables. This is especially true in Java as there is no such thing as a 
> global variable, so your variables live within a very limited scope.
>
> In addition you now have vastly superior development tools that can
> provide the needed insight into the code without adding extra syntax into 
> the code. This is especially true in VB where there is only one IDE that
> is used.

Perhaps it is ONLY true in VB?  Having "better" tools doe not eliminate the 
need, IMHO, as I stated by offering up the PRINTED code during 
reviews...what cool tool do you use to understand the variable types then?

>
> Hungarian notation had a time and a place, and it was valuable in that
> time and place. However, technology and  language design has progressed
> since then and in my opinion it is no longer of any value in Java and is
> in fact damaging to the overall quality and understandability of the 
code.

Finally!  You've stated your opinion as an opinion, but you don't seem to 
offer any real qualification as to WHY it is "damaging to the overall 
quality and understandability of the code."  Why?  Because the *screen 
font* choices you use makes a capital "I" look like an "l?"  I don't seem 
to have that problem.  Maybe *you've* been following a bit, too much?


>
> > a few other languages, but its programmers are not some version of
> > mutated pygmies from Mars.  They are intelligent humans with strengths
> > and capacities that enable them to write useful applications for
> > Windows.  Charlie Simonya "invented" Hungarian notation...or at least,
> >
>
> His name is Charles Simonyi and he originally wrote this up as part of 
his
> doctoral thesis. I believe he was still with PARC at the time, it wasn't
> until he joined Microsoft that it was widely used.
>
> > his use of it and his Hungarian ancestry represent our collective
> > understanding of the combined words and their meanings.
> >
>
> Another reason it was called hungarian notation is because people thought 
> it made the code look like it was written in hungarian. That is a very 
bad
> thing.

This apparently anecdotal information is obviously opinion oriented.  When 
you say that "people thought" it at least implies a majority.  I think that 
you should at least attempt to say that some people thought, unless you   
have some kind of numerical data to support your statement.  You say "is a 
very bad thing" ...what if you were Hungarian? :)  I don't think that the 
code looks like it was written in Hungarian, and I even know a few people 
with Hungarian ancestry.

>
> >
> >> conventions for Java. [1] It is also pretty useless in a pure OO 
language
> >> where you don't have pointers, it really just obfuscates the code.
> >
> > Huh?
> >
> > public class BadCode
> > {
> >   public	String 		a = "Using Hungarian Makes Sense."
> >   public	boolean		b = false;
> >   public	Boolean		B = new Boolean( false );
> >   public	int		i = 0;
> >   public	Integer		I = new Integer( 0 );
> >   public	char		c = 'c';
> >   public	Character 	C = new Character( c );
> >   public	double		d = 12345678.12345;
> >   public	Double		D = new Double( 12345678.12345 );
> >   public	float		f = 123456.7890F;
> >   public	Float		F = new Float( 123456.7890 );
> >
> >   public BadCode()
> >   {}
> > }
> >
> > versus
> >
> > String 		strName 	= "Charles Simonya";
> > boolean 	bIsRaining 	= false;
> > int		iCounter	= 0;
>
>
> Huh your self? You're arguing for hungarian notation vs. an example which 
> is simply poor programming? What makes you think that if a programmer is
> going to name their variables with one letter that they're going to name
> them any better if hungarian notation is brought into play? If you force
> them to use hungarian you're not magically going to get nicely named
> variables you're simply going to get variables with more letters in them. 
> And even worse if someone can't even get a basic principal like
> descriptive variable names right, what makes you think they'll be able to 
> apply hungarian notation consistently and correctly?
>
> > I don't see how the Hungraian "obfuscates" the code...I can see how it
> > would dramatically HELP the code...
>
> A more appropriate comparison would be to this code.
>
> String 	name 	= "Charles Simonyi";
> boolean 	isRaining 	= false;
> int		counter	= 0;
>
> Your example actually clearly illustrates one of the problems with the
> notation. When I looked at the variable bIsRaining I had to carefully
> consider what the variable was actually named and what was the notation.
> My first thought was that it was named Raining and the notation was bIs
> where the capital i looks exactly like a lower case L. It took me several 
> seconds to realize that the actual variable name was isRaining.

Change your FONT!  Jeez!  The next thing we'll hear is that you are using 
Vivaldi 6-point and couldn't tell if it as a period or an "o." :)
I vs l  my fonts make them extremely easy to discern.

>
> It is this need to consider the meaning of the prefix that is what causes 
> harm with hungarian notation. For the programmer who wrote the code
> originally it may be OK, but for other people it presents a serious
> distraction away from the core meaning of the problem being solved and

You and YOUR people thing again...speak for yourself.  I know many 
programmers who feel that Hungarian Notation is the preferred way to view 
code because it elucidates the code, not obfuscates it!  Walking by a piece 
of code on-screen at some programmer's workstation, one can readily and 
quickly discern its meaning because of it, IMO.  Otherwise, what do I have 
to do, hold his mouse over it, ask her to move the mouse to it?  "Say, what 
is that variable?"  Yes, good naming goes a long way towards helping make 
the variable recognizable, but that is ONLY PART OF IT.  If you state the 
TYPE in the name using HN, you can use the "rest" of the naming to state 
its PURPOSE.  Of course, you can say that it makes the code unreadable to 
YOU, but to any unknown number of OTHER programmers, it makes it clearer. 
 You don't have to choose to use it, but PLEASE...quit saying "people" as 
if it includes everyone but "the programmer who wrote the code originally."


> into a focus on the mechanics of the programming language. The whole
> reason we use higher level languages is to move away from focusing on the 
> mechanics required by the machine and into a focus on the problem domain. 
> Anything you add that forces your focus back to the mechanics, in places
> where it is unnecessary, is a step backwards.

I can agree in general with this comment.  However, I'm not sure that 
"forces" is the term I'd use.  Does a STOP sign being red "force" you to 
stop?  It is a POWERFUL reminder that something is *designed to happen* per 
its organization and intended usage.  If code has type information in it 
through the use of HN, it is, IMHO, a reminder to help keep you out of the 
weeds and from having to remember the type later in the code.  Your "glass 
half empty" argument seems onesided based on your opinion and effort to 
CLAIM that HN is bad.  I can easily agree that it is not for everyone, but 
why do you go to so much effort to refute it?  ...you obviously think that 
it *is* BAD.  Even your own argument, "in places where it is unnecessary" 
suggest that a JUDGEMENT call is required for at least nearly every 
situation.  So, what are you trying to do by saying HN is bad, make a 
judgement call for everyone? ...and for every situation?

>
> Your example also points out why it shouldn't be needed when you use
> proper variable names. Well chosen names will imply their types, as the

Well chosen names do imply their types.  My argument is that the hardest 
thing for programmers to do (other than implement good exception handling!) 
is to come up with useful variable names (includes functions).  Requiring 
the use of HN "forces" them to at least define the type such that they must 
only come up with the purpose of the variable, which, IMO, reduces the 
"load" of having to come up with a more "complex" name that "implies" (I 
don't want types being implied, I want them to be stated so there is NO 
DOUBT) both the type and the purpose.


> names you chose do when stripped of their prefixes.

Again, this is your opinion...possibly brought on by your lack of a 
suitable screen font to distinguish the variable names adequately...

>
> By using hungarian notation, you're basically making the statement that
> "type is the most important aspect for a variable". I would argue that
> "meaning is the most important aspect for a variable and that type is a
> very secondary consideration". I believe that if you want to improve the

And...you'd lose.  In a strictly typed language, such as Java, your type 
information is paramount.  If you happen to consider type information in 
your code secondary to its purpose, fine, however, to ensure it compiles, 
type correctness must be first.  To ensure that it performs as desired, 
purpose comes secondly.  The basic sequence of steps suggest to me that the 
priority is built into the order.  Of course, that's just my opinion :)


> understandability of your code then focus on choosing better variable
> names, not on adding unnecessary type information to names.

You and your "unnecessary" ...jeez.  Let me break this down for you.  If 
the COMPILER *must* have the type information correctly entered for it to 
compile, it should be *necessary* for a programmer to ensure that the type 
information is correctly entered.  IF naming a variable with type 
information included is used, AND a programmer can readily discern type, 
THEN the successfulness of the code compiling seems at least likely to 
improve.

>
> > Note this class (fragment) that I wrote for a simple racing "stats"
> > thing for one of the local drag racing clubs where I participate.
> >
> > public final class Car
> > {
> > }
> >
> > What is so obfuscating about that?
>
> It adds syntax that is unnecessary and forces you to consider the type of 
> a variable before considering what the variable is for. This gets in the
> way of understanding the intention of the code by forcing you to first
> consider the mechanics of the code. Even in code that I wrote my self I
> found this to be a problem when I used hungarian notation.

Once you are *proficient* at using HN, the type info is "second nature." 
 Perhaps you are simply not proficient enough in using HN?  It is like the 
stop sign being red.  Or, like it being octagonal, too.  If the shape 
doesn't *reinforce* its purpose, the color will and if THAT doesn't work, 
maybe the word STOP will help?  Jeez...you sound like you can't get over 
the fact that strName tells you it is a String and that clouds your 
thoughts and starts FORCING you to think about some kind of mechanics...of 
what, how to use a String?  Gee...maybe if something *reminded* you how to 
use the String (or that you even should use String methods on this member!) 
it wouldn't be a BAD thing...why are you having such a hard time getting 
over the hump?  Is it too difficult for you to master?

>
> My argument is from the psychological perspective of understanding the
> code, not from the perspective of adding as much information as possible. 
> I believe that the added information simply gets in the way and causes a
> series of minor distractions that in the end harm productivity. My
> argument is probably irrelevant if you are the only person who sees your
> code, my concern is only team environments. This was the domain for the
> original question.

It is the entire TEAM environment that it helps the most, as I've stated in 
my opinion.  Remember the code review in the conference room at 10:30 next 
Thursday?  You've printed up 5 copies of your code for your peer review and 
you're sitting down without an IDE in front of anyone and NO ONE has even 
seen your code before, wham, the HN makes it immediately clear to THEM what 
your member type is from anywhere within the code...unless, of course, you 
decided to print it out using your favorite script font...! :)

>
> >
> > How can it possibly be obfuscation?
> >
> > IListenerBroadcast
> > ITerminalOutput
> >
>
> Because it provides irrelevant information and changes the meaning of the 
> name to be logically incorrect.

WHAT!?  How dare you say irrelevant?!  It is irrelevant because you don't 
think it is relevant?

>
> Let's take your Car class as an example. You obviously designed that 
class
> with one particular type of car in mind. So in your code you declare an
> instance of the class as something like.

I don't think you have any idea as to the purpose that I "designed" the 
class.  The "class" happened to be a final class...but you PROBABLY didn't 
notice that huh?  It was "designed" (I use the term very loosely, because 
it is a completely inadequate *class* design where all of its members are 
public so that I wouldn't have to write any accessor/mutators) simply to be 
a data "holder" or representation of a column of data contained within a 
guy's spreadsheet.  He had already defined the data that was meaningful to 
him, I was simply creating a class to stuff the data into a better 
orginization/deployment method when "translating" it from his spreadsheet 
to XML output.  My use of this class in this thread was to illustrate the 
naming of the members that *I use* rather than the obviously not very 
fantastic "design" of the class.  However, if I'm reading your reply 
correctly, you are subsequently subclassing my final class.  Here is a 
situation where HN *could have helped* if it didn't directly contradict the 
Java coding standard...imagine "type info" for the final class!?  Instead 
of class Car, it would be class cfCar or something...doesn't matter, as 
long as everyone can recognize it...which is probably another reason for 
not having one for it! (as if the contradiction isn't enough)  IF that 
convention DID apply, though, you'd have KNOWN (without having to have read 
the code carefully enough!) that the class was not "subclassable" ...and, 
your entire *following* argument wouldn't have happened!

>
> Car winningCar;
>
> Now what happens if you decide later that a car could be either a real 
car
> or it could be a matchbox car and the implementation of the actual car
> class will be completely different. You would then convert Car into an
> interface and add classes for RealCar and MatchboxCar that implement that 
> interface. If you follow your naming convention you would also have to
> rename Car to ICar just because it became an interface. So you then have
> to change your declarations to.
>
> ICar winningCar;
>
> What is the logical reason for reflecting this change in the actual 
syntax
> of the program? Seems to me the logical way is to keep the interface 
named
> Car because after all it "is" still a car. The fact that in actual

NO! It IS NOT a car. (or Car)  The key difference is that the interface is 
not an object instance!  Only an object that implements the interface may 
be instantiated.


> programming language implementation it is an interface is completely
> irrelevant. It obfuscates the code by forcing you to consider the 
question
> "is the fact that this is an interface an important piece of 
information?"
> when in the vast majority of cases it will not be. It is simply a Car and 
> interface or not doesn't make one bit of difference. So again by using
> this naming convention you're placing an emphasis on something that
> provides more information, but in doing so forces you to consider
> something that is irrelevant to actually solving the problem.

Who are you trying to convince, me or you?!  The fact that it *is* an 
interface *must* always be relevant or else, why would we have interfaces 
if they were no different than "classes?"  Your apparently firm belief that 
everything others do is irrelevant SUGGESTS to me that you're not really up 
on a lot of topics regarding programming and somehow think more highly of 
yourself and your skill set.  Sure, we all make mistakes and we all 
sometimes say crap that is "foolish" (Remember, Don't be a fool?  ...kinda 
like a "High Wind Advisory?" :) but your incessant efforts to say that it 
is all irrelevant is simply overstated.  Let's say that you were somehow 
"right." (as if anything is clearly right)  Why would so many other people 
firmly believe that their use of HN be "right?"  The fact, plain and 
simple, is that it is "right" for some people, and, perhaps not "right" for 
others.  BUT...your argument that it is irrelevant AND that they're just 
following without really understanding _DEFINITELY SHOWS_ your own 
ignorance and lack of respect for many, many other (supposedly intelligent) 
programmers.  Anyone who would publicly show such disrespect for such a 
large body of "people" (implies a lot of them, perhaps a few million?) 
should be considered, IMHO, as someone who is simply spewing forth without 
any gray matter working in support of his opinion.  The sheer proportion of 
this "problem" suggests that SMARTER persons than either you or I, are 
justifiably correct in their use of Hungarian Notation...and that no matter 
how profusely you spew that it is BAD...it really CAN NOT POSSIBLY BE (all) 
BAD for at least that group who uses it.

>
> >
> > ...see any difference?  I'm thinking that perhaps your "obfuscation"
> > comment is slightly exaggerated based on your bias toward NOT seeing 
HN?
> >
> Your use of obfuscation is an exaggeration, of course it is also a common 
> one in the programming world. Doesn't change the english definition of 
the
> word though, it simply means to confuse. Obfuscation is obfuscation your
> example just takes it to an extreme.

Your *definition* of obfuscation is wholly inadequate, much like the rest 
of your arguments.  Obfuscation does NOT "simply mean to confuse."  In 
fact, it means to confuse SO MUCH that the Dictionary.com definition states 
this:

To make so confused or opaque as to be difficult to perceive or understand: 
"A great effort was made... to obscure or obfuscate the truth" (Robert 
Conquest).

I think that YOUR "great effort" made to denounce HN is at least an 
appropriately used "obfuscation" through your own use of argument...errr, 
or lack thereof!

>
> >
> > Also, there is something to be said about being flexible enough to
> > understand BOTH sides of the topic.  I can understand not wanting to
> > "convert" to HN, but I don't see the need to justify it as 
"obfuscating"
> > the code.  The goal of HN is to make the code CLEARER, and it does,
> > whether or not you've accustomed yourself to accepting it or not.  I
> > even use HN in naming my XML attributes...where the types must always 
be
> > the same within the "code" (xml file) but handled differently in the
> > parser.  I think that there are certainly different strokes for
> > different folks, but this is not a religious thing.  If you following
> >
> Ahh, so you're arguing that the notation can be used to make bad code
> easier to understand. That is probably true, but why bother? If you can't 
> get people to listen to feedback on code quality, how is hungarian
> notation really going to help? Sure saying that if HK was used the code
> would be easier to understand is nice, but it's no different then saying
> if the code had just been written properly that it would be easier to
> understand. My concern is improving real code quality, in that scenario
> hungarian notation is nothing more then a distraction. In my opinion
> you're fighting the right war (code quality) but on the wrong 
battleground.

I guess that I'm not really THAT interested in your opinion(s) anymore... 
:)

>
> >
> >
> > I don't ask that you or anyone else use HN if it doesn't match your
> > "local" conventions/standards.  I do, however, ask that if you must use
> > a global, at least indicate it using HN.
>
> I don't disagree with you here, but then Java doesn't have global
> variables either. :-)

While the JDK may not offer a true "global," you can easily implement a 
"global" in Java, at least at the application scope.  Of course, there are 
those who would argue that a function name that is the same for all classes 
is, in fact, a global variable.  Consider java.Object.hashcode() or 
java.Object.toString(), which are "global" functions implemented by every 
single Java object.  The function *names* are therefore "globals" even 
though each resolves to a different class instance.  This is the age-old, 
mother-of-all-objects single inheritence path argument...at least bent out 
of shape for the purposes of mentioning them here.

>
> >
> Kimbro Staken
> Java and XML Software, Consulting and Writing 
http://www.xmldatabases.org/
> Apache Xindice native XML database http://xml.apache.org/xindice
> XML:DB Initiative http://www.xmldb.org
>

Hopefully I haven't pissed you off, at least, not too much...but perhaps 
just enough to give the "benefit of doubt" to the many programmers who feel 
that HN is a useful tool.  You can argue against it, but don't call us (I 
don't use VB) stupid monkeys.

Take Care.

Rob!