dokos@inmet (08/23/89)
There is an interesting discussion of "Hungarian" notation (among other things) in an interview with Simonyi that can be found in a book by Microsoft Press, called "Programmers at work". Interesting reading.
jeff@cdp.UUCP (08/26/89)
Hungarian notation is being promoted by the Microsoft folks as the
best thing since sliced bread. But there's a sad (funny?) side
to this: Hungarian notation flies in the face of what we've been
trying to teach and practice for years with the notions of information
hiding and abstraction. Hungarian notation encodes the type of each
primitive data object into the name of the object. The loss of
abstraction should be obvious: for example, changing the underlying
implementation of a variable requires that its name also be changed.
I'm not familiar with the environment at Microsoft -- it's conceivable
that this is truly one step forward for them -- but for many of us,
it's one big step backwards.
Jeff Dean
uunet!pyramid!cdp!jeffpaulkle@microsoft.UUCP (Paul Klemond) (08/29/89)
In article <138300001@cdp> jeff@cdp.UUCP writes: > >Hungarian notation is being promoted by the Microsoft folks as the >best thing since sliced bread. But there's a sad (funny?) side >to this: Hungarian notation flies in the face of what we've been >trying to teach and practice for years with the notions of information >hiding and abstraction. Hungarian notation encodes the type of each >primitive data object into the name of the object. The loss of >abstraction should be obvious: for example, changing the underlying >implementation of a variable requires that its name also be changed. > >I'm not familiar with the environment at Microsoft -- it's conceivable >that this is truly one step forward for them -- but for many of us, >it's one big step backwards. 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 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. 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. With C++ I guess there will be more redefinition of * [] and the other operators. in that case the primitive abstract tags will be used more than the type constructions. It will be still hungarian. even if * or [] are redefined, if you want to distinguish between a thing "foo" and its handle, it is a good idea to call the handle pfoo and define the operators so that the *pfoo = foo type match will be correct. If yo 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, Hungarian and Abstraction can be used together, something Mr. Dean failed to recognize. ---------- paulkle@microsoft uunet!microsoft!paulkle These views don't necessarily represent those of Microsoft Corp. But what do you think?
jeff@cdp.UUCP (09/02/89)
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
EGNILGES@pucc.Princeton.EDU (Ed Nilges) (09/03/89)
I have been following the discussion of Hungarian notation with some
interest. Actually, the idea is not new: I read an IBM standards
textbook which enjoined something of the same practice, reflecting
data types in data names, on Assembler programmers.
I much prefer a notation which prefixes each variable by a Dewey
Decimal code reflecting the position of the variable's owner in
the program...if routine "aa" declares and uses a variable length,
then the name of the variable becomes aa_length. Where the overall
architecture of the program is a hierarchy (frequently the case in
business programming, less often the case in scientific or systems
programming), then the Dewey Decimal code accurately reflects the
variable's owner, and the owner's position in the hierarchy:
a_mainline owns a_i, a_j, and calls
aa_read_parms, which owns aa_parmcount
ab_read_next, which calls
aba_check_next
.
.
.
Where routines crop up that violate the hierarchy, they get prefixes
from the end of the alphabet. Again, such routines arise more
frequently in scientific, systems software, and event-driven
routines...note that the above is probably a simple batch application.
However, in nontraditional code, there are frequently mini-hierarchies,
miniature city-states of code that are called in a complicated
network, but have themselves a hierarchical structure.
Hungarian notation is a threat to effective maintenance because
incompetent (or simply under-informed) maintainers may make changes
that invalidate the information contained in Hungarian notation.
Of course, the same charge applies to Dewey Decimal notation or
indeed any friendly attempt to document one's code. My (quite
unscientific) personal observation has been that the sort of
design changes that invalidate the architectural information
provided by Dewey Decimal notation are much less frequent than
the sort of implementation changes that invalidate Hungarian notation.
************************************************************************
"Oh, I could prophesy: but thou art dust, Harry, and food for..."
- Henry IV, Part II