neil@swdev.Waterloo.NCR.COM (Neil A. Law) (09/03/89)
Thank you all for your input, the following is a summary of that information.
I've read the article from PC Mag and it seemed to be a good intro.
As far as our situation, it appears we will not be going to Hungarian in
the immediate future.
============================================================================
I have used a variation of Hungarian notation. (Q: is there a reference to this
other than from Microsoft? I've used it WRT what Microsoft suggests for MS
Windows programming.) The reason for the variation is just that I don't like
some of the prefixes Microsoft uses, in particular
szStringName (I usually use sStringName)
lpszStringPtrName (I usually use lpStringPtrName)
Any information I have is purely anecdotal -- no claims that it increases
productivity or code readability...
I personally like it (with modifications from Microsoft's suggestions), and
most of the Windows programmer's I've worked with at least use it. One of the
common modifications I've seen was the additional prefix g, for a global
variable (most helpful to point out possible side effect problems!).
Most people who haven't tried it first look at it and barf, but after trying
it for a while seem to like it. (As I said before, most of the programmers
I've worked with are still using it, so nnn people can't all be wrong...)
--Bill Turner (bturner@hp-pcd.hp.com)
HP Corvallis Information Systems
===================================================================
I used Hungarian for a couple of years at Xerox while I worked for
Charles Simonyi (the Mad Hungarian) Himself.
It's best in typeless or nearly typeless languages like BCPL and C, and in
languages with a restricted number of characters in identifiers. In
strongly typed languages like Mesa, Modula-2, or Ada, it's less useful,
since you can tell what a variable is by looking at its declaration.
I still use it on and off in C. For example, if I have a quantity
which is represented both as an integer (internally) and as a string
(externally), I might call the two variables iMumble and sMumble.
I don't use it religiously any more, but it's best when used
religiously by all the programmers on a team. Why, I still remember
one variable name from years back... the prefix "mp" meant a map
(array) from one type to another. A "ww" was a window, and a "wwd" was
a window descriptor. It was therefore obvious that the variable named
"mpwwwwd" was an array whose domain was windows and whose range was
window descriptors... i.e., that the statement "wwd = mpwwwwd[ww]"
made sense.
And, of course, since the structure of a Hungarian name is nounModifier,
your subject should read experiencesHungarian or expHung...
Write back if you have any questions...
Bob Weissman
Domainish: bob@omni.com
UUCPish: ...!{amdahl,apple,pyramid,sgi,tekbspa,uunet}!koosh!bob
===================================================================
Won't it make things tricky if we program in Hungarian?
Seriously though, if Smalltalk/V notation is Hungarian, we have similar
thoughts
here. We like the conventions used in Smalltalk but have only been using them
for 2-3 months. As for the programming *concepts* in Smalltalk, they still
get my head reeling ... :-)
------------------------------------------------------------------------------
"All opinions expressed are the exclusive problem of the undersigned"
Alan W Officer - Systems Group alan.officer@dundee
Self-Service Systems Division Tel +383 414444 Ext 3027
E&M Dunfermline - on Scotland's East Coast Fax +383 416661
===================================================================
In regards to Charles Simonyi and the Hungarian Naming Conventions, the book
"Programmers at Work" from Microsoft Press may be a source. That's where
I read about this naming convention. The book is a series of interviews with
influential/great programmers, including Simonyi. I believe there was an
appendix with additional information on the technique. This book is widely
available, or contact MS.
-- Dennis Moore, my own opinions, etc etc etc
===================================================================
We have been using the Hungarian notation in our MS-Windows programming for
several years now here at SE-San Diego. Our application suite consists of
many modules (some modules are windows applications and some are dynamicall
linked libraries). Nearly all of the modules talk to each through message
passing.
We have extended the Hungarian notation slightly so that any variable can
be determined to be local, or global, and if global, which module it is
defined in.
e.g., nFooBar (local integer)
nUIFooBar (global integer, defined in User Interface)
nRSFooBar (global int, defined in RS232 com module)
We use a similar notation on procedure names to indicate which are called
from outside the current file.
We have found the notation beneficial when maintaining code written by
someone else.
Personnaly, I would like to be able to look at a variable name and know
immediately not only which module, but which source file it is defined
in. Of course there is a limit to how long you want variable names to be
(especially considering ANSI uniqueness limitations).
On a side note, I'm looking forward to the day when my editor can tell
me exactly where variables are defined through some hypertext capability.
rich.hume@sandiego.ncr.com
===================================================================
For Charles Simonyi's thesis: Meta-Programming: A Software Production Model
try:
University Microfilms, Inc.
300 North Zeeb Road
Ann Arbor, Michigan 48106
800-521-0600 or 313-761-4700
The thesis was done at Stanford, dated Dec 1976, and copywrite 1977.
It was also reprinted as a techincal report from Xerox Palo Alto Research
Center, number CSL-76-7 December 1976, under the same title.
Randall Neff
===================================================================
>If anyone has any articles on the subject I would appreciate if you could send
>me a copy (mail or email). I would especially be interested in obtaining a
>copy of Charles Simonyi's Meta-Programming thesis.
>
There is an article on this subject in PC MAGAZINE, march 14th. 1989,
page 329, written by Charles Petzold. It is titled 'Speaking the
language of the PM API'.
By the way, you should talk to your colleagues at E&M (or is it S&E) in
Columbia, SC. They use Hungarian notation when they program the WS-300,
or more commonly known as the nGen from Convergent Technologies.
I didn't like the Hungarian notation in the start, but after a while I
realized it was much easier to maintain code written with the Hungarian
notation.
--
Steinar Overbeck Cook, Fellesdata a.s, P.O. Box 248, 0212 OSLO 2, NORWAY
===================================================================
In reference to "Hungarian notation" and its intended usefulness
I have included a section of Charles Petzold's book 'Programming
Windows' which explains its origins and proper aesthetics:
'Windows programmers often use a notation for variable names that at first
looks peculiar. The variable name is given an initial lowercase letter
or letters that denote the data type of the variable, followed by a
descriptive name in mixed uppercase and lowercase--for example:
WORD wBufferSize
DWORD dwFileSize
The idea here is that the variable itself reminds you of the data type
of the variable. This is often called Hungarian notation in honor of the
legendary Microsoft programmer Charles Simonyi.
Although it is very simple, Hungarian notation is enormously helpful
in avoiding dumb errors. If you happen to code the assignment statement:
wBufferSize = dwFileSize ;
the error is much more evident that if you had used normal C variable
names like buffersize and filesize:
buffersize = filesize ; '
Mr. Petzold goes on to present a table of prefixes for various classes
of data objects. I want to stress that the use of mixed case makes the
convention more effective and is part of the notation. A string of
lowercase letters makes it difficult to distinguish where the type
definition ends.
From: Rob Sadler <sadler@sw.mcc.com>
===================================================================
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!jeff
===================================================================
>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?
===================================================================
I worked on a project that used a naming scheme like the hungarian
notation. We did not follow the exact format used by Microsoft.
At first, I did not like it, due to the extra typing. I now
use it whenever programming becuase of the greater code
readability. The problem stated about loss of data abstraction
did not seem to be a problem in practice. We also used
macros (denoted m<macroname>()) for data structure access,
so any changes to data structures were hidden from the code
in the macro definition.
I will push for the use of hungarian notation whenever talk
of coding standards for any project I work on rears its
ugly head.
Tom Harper thh@hpda.HP.com
--
==========================================================================
>>>> Neil Law, Systems Architecture <<<< 519-884-1710 x499
E&M Waterloo, NCR Canada Ltd, 580 Weber St. N., Waterloo, Ont. N2J 4G5
N.Law@Waterloo.NCR.COM uunet!ncrlnk!ncrwat!swdev!neil