Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.csd.uwm.edu!uakari.primate.wisc.edu!ames!sgi!arisia!cdp!jeff
From: jeff@cdp.UUCP
Newsgroups: comp.software-eng
Subject: Re: Experiences with Hungarian Nami
Message-ID: <138300002@cdp>
Date: 2 Sep 89 04:52:00 GMT
References: <974@swdev.waterloo.ncr.com>
Lines: 99
Nf-ID: #R:swdev.waterloo.ncr.com:-97400:cdp:138300002:000:4960
Nf-From: cdp.UUCP!jeff    Sep  1 21:52:00 1989


paulkle@microsoft.UUCP (Paul Klemond) writes:

> I brought this view to the attention of Charles Simonyi, the "inventor"
> or hungarian notation (Charles is Hungarian, thus the notation's name).
> Here's what I said to him:
> 
> Above is someone's critical view of Hungarian. I see points for both sides:
> 
>   1.  The "reality" of doing competitve (high-performance) programs
>       forces us to use the environments we do, the limitations of
>       which we must live with.  Hungarian is of benefit to us in
>       these more practical, more competitive environments.
> 
>   2.  A fundamental change in our environments, one we should make,
>       renders Hungarian substantially less useful.
>
> Here's his [Simonyi's] reply:

> the point is clever, but was probably made after contemplation rather
> than practice. Hungarian in fact helps abstraction in the following
> way: primitive tags (such as ww for window numbers) represent the
> abstraction itself rather than the underlying representation (which
> would be int, char, or long in this case, maybe encoded into a typedef
> called WW. So in this case Hungarian is more modern than using just 
> the "int" type and some random name. CloseWw(ww), for example, is
> really an operation Close on the type ww.

I've spent several months working on an OS/2 project.  The OS/2
documentation and header files use Hungarian notation.  My complaints
about Hungarian notation are a result of direct experience with the
system.  When you're programming in C, you ususally set up your data
types, define your variables, then go.  In Hungarian, you are forced
to acknowledge data types every time you enter the name of a
variable.  Some may consider that reasonable type checking.  I'd much
rather use ANSI prototypes and/or lint.

> What the msg. is proably referring to is the practice of name
> construction following the type construction, e.g. pch for a pointer
> to a ch, etc. Here if you change the representation, you OUGHT to
> change the name as well. True enuff, but the fact is that our
> * operator applies only to pointers. So the p simply is a warning
> that the programmer is using the standard * operator someplace.
> If the representation changes, the places where the quantity is
> used, should be visited and checked.

I was originally addressing the issue of simple data types.  Let's
take an example.  In Hungarian notation, a short variable that
maintains a running total might be called "sTotal".  A subsequent
change to make this a long would require the name to be changed to
"lTotal".

Suppose I have an OS/2 application, and Microsoft decides to change
one of their underlying data structures.  When I try to recompile my
program, I will get messages saying something about "unknown structure
member".  On the other hand, if OS/2 had relied on ANSI-style
checking, then the error messages would instead complain about a type
clash.

Now consider a vendor trying to maintain compatibility between old and
new versions of their software (e.g., Microsoft and OS/2 versions).
Can I just recompile my code under the new version, or will I have to
do extensive editing?  For example, if I reference a structure member
that was previously a short, and then that member is changed to a
long, I've got to edit my program.  In the traditional non-Hungarian
approach, all I would need to do is recompile.

Some folks have implied that this critique is somewhat academic, and
does not address the needs of programmers using current programming
environments.  The programming tools available today can do a
reasonable job of type checking.  In the PC environment, most of the
major compilers (including Microsoft) support ANSI-style checking.
In the Unix environment, machines that don't have the latest
ANSI-compatible compiler still have lint.  (I'm not familiar with the
C compilers in other environments.)

...

> If to want to change the widow handle from a integer to a pointer to
> a window descriptor, I would stay with the old names ww for the clients.
> Within the operations which KNOW how ww is implemented, I would
> use the locally descriptive names, say pwwd and understand that a
> kind of coersion is taking place from ww to pwwd at the operation
> side of the interface. What the client can not or should not know,
> need not and should not be encoded into the hungarian type construction.

So much for consistency.  Sometimes Hungarian names reflect the
underlying types, sometimes they do not.

Hungarian notation seems to be more of a cute hack than a serious
programming tool.  ANSI-style checking, for one, is a much better
approach to the same problem.  But here's where the argument becomes
academic: given Microsoft's position in the software market, many of
us will have to live with Hungarian notation, whether or not we like
it.


	Jeff Dean
	uunet!pyramid!cdp!jeff