Hungarian notation
John Jacob
I have been using c++ for a while, and mostly developed with MFC. After a
while, I adopted the hungarian notation, it being the style used in most
code I had come across.
However, I keep seeing opinions that hungarian should not be used.
What are the actual disadvantages of hungarian? Using hungarian does not
affect speed or stability, and does not affect the person who wrote it.
Variable naming is done so that the NEXT person who writes finds it easier
to understand the code.
So, does hungarian make code harder to maintain? Does it make code more
difficult to read?
Are there any alternatives to hungarian - seeing that just naming variables
at random can cause problems (e.g where a name "file" would be used in a
single project to mean a handle to a file, a filepath, a CFile object etc.)
Thanks,
-John J.
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
[ about comp.lang.c++.moderated. First time posters: do this! ]
Paul Floyd
>Hello,
>
>I have been using c++ for a while, and mostly developed with MFC. After a
>while, I adopted the hungarian notation, it being the style used in most
>code I had come across.
>However, I keep seeing opinions that hungarian should not be used.
>What are the actual disadvantages of hungarian? Using hungarian does not
>affect speed or stability, and does not affect the person who wrote it.
>Variable naming is done so that the NEXT person who writes finds it easier
>to understand the code.
>So, does hungarian make code harder to maintain? Does it make code more
>difficult to read?
>Are there any alternatives to hungarian - seeing that just naming variables
>at random can cause problems (e.g where a name "file" would be used in a
>single project to mean a handle to a file, a filepath, a CFile object etc.)
This is rather a religious issue.
However, here's my pennyworth.
It tends to link the variable name to concrete built-in types. It is far
less useful for user-defined C++ types. This 'hard link' is its
weakness, imagine having to port a major project to 64 bit, and having
to change not only all the types of many short/long/ints, but also the
variable names.
I think it's much better to define your own types in the first place,
then all you have to do is change a few typedefs.
A bientot
Paul
--
Paul Floyd http://paulf.free.fr (for what it's worth)
Mail as URL, replace 1st . with @
If more is better, are double standards better than single ones?
Carlos Moreno
John Jacob wrote:
>
> Hello,
>
> I have been using c++ for a while, and mostly developed with MFC. After a
> while, I adopted the hungarian notation, it being the style used in most
> code I had come across.
> However, I keep seeing opinions that hungarian should not be used.
> What are the actual disadvantages of hungarian? Using hungarian does not
> affect speed or stability, and does not affect the person who wrote it.
> Variable naming is done so that the NEXT person who writes finds it easier
> to understand the code.
> So, does hungarian make code harder to maintain? Does it make code more
> difficult to read?
> Are there any alternatives to hungarian - seeing that just naming variables
> at random can cause problems (e.g where a name "file" would be used in a
> single project to mean a handle to a file, a filepath, a CFile object etc.)
I personally dislike the hungarian convention -- I find it *much* harder
to read than using underscores...
Just let me put the above paragraph in hungarian notation and tell me
if you could read it:
IPersonallyDislikeTheHungarianConvention --
IFindItMuchHarderToReadThanUsing
Compare it to this:
I_personally_dislike_the_hungarian_convention --
I_find_it_much_harder_to_read ...
The underscores go practically as spaces. You can read the underscore'd
text looking at the text and your brain completes the missing pieces.
To read a hungarian notation text, you have to pay close attention to
each and every single character in the sequence... I find it horrible
and annoying...
That's my point of view... I know this is a topic where opinions (even
for C/C++ programmers) are pretty divided...
HTH,
Carlos
--
Andy Williams
"Paul Floyd" <pa...@free.fr> wrote in message
news:slrn9et5r...@bisanne.free.fr...
> [Hungarian notation] tends to link the variable name to concrete built-in
types.
The aim of Hungarian notation is to indicate the usage of a variable, not
its type (although for user-defined types that can often be the same thing).
For example, the common prefix "psz" for "pointer to zero-terminated string"
does not distinguish between ANSI and Unicode strings. You would only make
that distinction if your code had to deal with both and the actual type of
any string would therefore be crucial. Another common prefix is "cb" for
"count of bytes", where clearly it would be worth changing the name if the
variable became a "count of words".
You might also consider that, where a name's prefix does indicate a built-in
type, the fact that you change the name when you change the type is an
advantage - the compiler lets you know the extent of the change.
My personal experience is that good use of Hungarian notation makes code
much more readable, while poor use of the notation can lead to extremely
obscure code.
-Andy
Timur Aydin
> What are the actual disadvantages of hungarian? Using hungarian does not
> affect speed or stability, and does not affect the person who wrote it.
Nowadays modern software development tools come with code browsing features
that allow you to go to the definition of a variable, get a list of all
references, caller/called trees etc. For example, VC++ has very powerful
source browser support. Also, programmer's editors like Codewright and
Visual SlickEdit have code browser support. Cygnus Code Navigator is also
worth mentioning. Therefore, having the type as part of the variable name is
not such an advantage anymore.
I can think of these issues with using hungarian notation:
- If you change the type of a variable, you have to go and replace all the
variable names also.
- A real world program can be using many different types. Coming up with
good, intuitive prefixes is not easy and even if you were able to devise
good names, it is difficult to consistently use it, because it would be hard
to remember every prefix that corresponds to every type and you don't want
to constantly look up the prefix for types from a cheat-sheet. People that
advocate hungarian mostly focus on simple types like int, short, C style
string etc. What about STL classes? What prefix to use for an std::string,
std::queue, std::map etc? What prefix to use for another class library? In
the real world there are just too many types.
Timur.
James Dennett
>
> Hello,
>
> I have been using c++ for a while, and mostly developed with MFC. After a
> while, I adopted the hungarian notation, it being the style used in most
> code I had come across.
Sad but true.
> However, I keep seeing opinions that hungarian should not be used.
> What are the actual disadvantages of hungarian?
[My comments apply to "Hungarian" notation as commonly used
in MFC etc., and not to smarter versions which encode only
abstract type information.]
It's a crutch for languages such as C which don't have such
a rich type system as C++. In C++ it encodes in names
information which is not important; say I call my variable
vectorNames, because it's a std::vector, and later find out
that it ought to use a std::deque for performance reasons.
Then I'll have to either (a) rename it globally, or (b)
live with an incorrect name. Not to mention that "names"
is a more readable name, and its terseness might encourage
a more descriptive name such as "employeeNames".
> Using hungarian does not
> affect speed or stability, and does not affect the person who wrote it.
It affects the person who wrote it by making them think
too much in terms of implementation details, and not enough
in terms of *meaning*.
> Variable naming is done so that the NEXT person who writes
> finds it easier to understand the code.
Possibly; it can aid uniformity, but at the cost of absolute
clarity.
> So, does hungarian make code harder to maintain?
As per by "vectorNames" example above, yes. Hungarian
notation makes code harder to maintain.
> Does it make code more
> difficult to read?
Yes, because most of the types in good C++ code are not
primitive types, so you have to either (a) write a full
type name in your Hungarian wart, making identifiers
much longer for no gain, or (b) invent bizarre abbreviations
for type names which are a barrier to entry for those
wishing to read your code.
Not to mention that it's not clear how Hungarian notation
could apply in generic code.
> Are there any alternatives to hungarian - seeing that just naming variables
> at random can cause problems (e.g where a name "file" would be used in a
> single project to mean a handle to a file, a filepath, a CFile object etc.)
Maybe a meaningful name would avoid that: PathToConfigFile,
ConfigFileStream, ... . I find that avoiding Hungarian
notation helps me to concentrate on the meaning of my
objects, where Hungarian notation leads people to name
objects often solely based on their concrete type. The
meaning is usually more resilient through changes than
is the concrete type.
-- James Dennett
Erik Max Francis
> Just let me put the above paragraph in hungarian notation and tell me
> if you could read it:
>
> IPersonallyDislikeTheHungarianConvention --
> IFindItMuchHarderToReadThanUsing
>
> Compare it to this:
>
> I_personally_dislike_the_hungarian_convention --
> I_find_it_much_harder_to_read ...
Um, that's not Hungarian notation. Hungarian notation is when the type
or usage of a variable is embedded in its identifier.
--
Erik Max Francis / m...@alcyone.com / http://www.alcyone.com/max/
__ San Jose, CA, US / 37 20 N 121 53 W / ICQ16063900 / &tSftDotIotE
/ \ Covenants without the sword are but words.
\__/ Camden
Esperanto reference / http://mirror/alcyone/max/lang/esperanto/
An Esperanto reference for English speakers.
Erik Max Francis
> However, I keep seeing opinions that hungarian should not be used.
> What are the actual disadvantages of hungarian? Using hungarian does
> not
> affect speed or stability, and does not affect the person who wrote
> it.
> Variable naming is done so that the NEXT person who writes finds it
> easier
> to understand the code.
> So, does hungarian make code harder to maintain? Does it make code
> more
> difficult to read?
It has one of the disadvantages that all such enforced style confers:
If it's not used everywhere, it's suddenly much less useful. Another is
what happens when code changes -- you either have do a search and
replace or leave the notation inaccuracies (which happens _a lot_). A
third issue is that it's used inconsistently -- is it i for integer, or
c for count, or something else? Not to mention that it's appalling
ugly.
Much of the advantages of Hungarian notation can be achieved by just
using sensible, descriptive identifier names.
> Are there any alternatives to hungarian - seeing that just naming
> variables
> at random can cause problems (e.g where a name "file" would be used in
> a
> single project to mean a handle to a file, a filepath, a CFile object
> etc.)
With small functions and good code browsers this really isn't a problem.
Another issue I have is that Hungarian notation tends to lead to lazy
program. You dive right in a block of code that you haven't seen before
because you "think" you know what's going on thanks to those prefixes,
instead of actually looking up the types of all the identifiers that are
swimming around. It would be much better from a programming standpoint
to not have the (sometimes misleading, sometimes wrong) "hints" that
Hungarian notation provides and actually look up what the identifiers
really are then relying on a one- or two-letter hint. As I said, with
code browsers and C++'s strong typing, this is much less of an issue
these days.
--
Erik Max Francis / m...@alcyone.com / http://www.alcyone.com/max/
__ San Jose, CA, US / 37 20 N 121 53 W / ICQ16063900 / &tSftDotIotE
/ \ Whom God has put asunder, why should man put together?
\__/ Ralph Waldo Emerson
Physics reference / http://www.alcyone.com/max/reference/physics/
A physics reference.
Assaf Lavie
Most of the API, code samples and documentation regarding MS stuff is done
in this notation...
This fact alone makes it pretty obvious that most Windows programmers that
will read your code, will probably understand the notation and even be
accustomed to using it. There are alternatives, but if you are used to it,
and so are your co-workers, I say keep using it.
--
Assaf Lavie
"John Jacob" <jo...@jacob.com> wrote in message
news:9ckfqe$aa0$1...@rzsun03.rrz.uni-hamburg.de...
> Hello,
>
> I have been using c++ for a while, and mostly developed with MFC. After a
> while, I adopted the hungarian notation, it being the style used in most
> code I had come across.
> However, I keep seeing opinions that hungarian should not be used.
> What are the actual disadvantages of hungarian? Using hungarian does not
> affect speed or stability, and does not affect the person who wrote it.
> Variable naming is done so that the NEXT person who writes finds it easier
> to understand the code.
> So, does hungarian make code harder to maintain? Does it make code more
> difficult to read?
> Are there any alternatives to hungarian - seeing that just naming
variables
> at random can cause problems (e.g where a name "file" would be used in a
> single project to mean a handle to a file, a filepath, a CFile object
etc.)
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Ken Hagan
Carlos Moreno <mor...@mochima.com> wrote...
>
> Just let me put the above paragraph in hungarian notation and tell me
> if you could read it:
>
> IPersonallyDislikeTheHungarianConvention --
> IFindItMuchHarderToReadThanUsing
>
> Compare it to this:
>
> I_personally_dislike_the_hungarian_convention --
> I_find_it_much_harder_to_read ...
>
> The underscores go practically as spaces. You can read the underscore'd
I don't think BiCapitalisation is what John meant by Hungarian, but since
you raised the subject, and since...
> That's my point of view... I know this is a topic where opinions (even
> for C/C++ programmers) are pretty divided...
...I will toss in a response. Yes, the underscores read as spaces. That's
why I don't like them. Names should be read as single tokens in my brain,
so anything that cause my brain to read "whitespace" causes a mental parsing
error. :)
The question is largely irrelevant anyway. Good programmers should be able
to read all the popular styles for layout and naming, so it doesn't matter
what style they write in.
Attila Feher
Let me drop in, as a Hungarian. :-))
Please note, that the Hungarian notation is something developed for the
C language, and not the C++. In C, it was (is) quite simple to come up
meaningful prefixes for the "few" types, which make sense in a
particular domain (like Windows programming). With C++, it is really
more difficult situation. In C you could have global, filewide static,
local, static local variables and probably structure members (what you
have never ever accessed without the structure (usually pointer)
variable). In C++ you may have (in addition) member variables of
classes (struct), static member variables... not to mention the
different kinds of functions, classes (templates, traits, singletons
etc.)
So Hungarian notation in C++ is something tricky if not at all
meaningless (it might not be). Let me collect my toughts which were
started up by the thoughts of others in this thread:
- in C++ (class) types are interchangeable (child-base). So if I use a
container which is vector today, but will be list tomorrow... My code
might not change anywhere. Why change variable names?
- in C++ the number of types is high. Just using STL and an in-house
class library can add so many types, that it makes the prefix creation
job a huge administration issue.
- in C++ encapsulation plays an important role! I don't care what is
the type as long as it provides the operations (interface). So this is
more important than the actual type (implementation). That is the
reason my variable names usually refer to the "class" or "high concept",
rather than the underlaying type. Like: xxxTable, xxxCounter,
xxxMaximumLength, xxxMessage etc.
- C++ development is usually supported by some (UML?) model, which gives
the insight, so it is not so difficult to understand the code, once you
have read the model and know the terms of the problem domain and the SW
itself.
So I guess it is important for a C++ program, too, to give a good hint
about what is the variable. But I doubt that the Hungarian notation is
well suited for that purpose. For prefix I usually use something
talking about the variables placement and constness, like aIsbnTable is
an argument (non-const reference as usual) and mIsbn is a member,
cgMaxTimers is a global constant etc.
The name itself talks about the type, not before (as prefix) the name,
but as part of the name, as we talk. We talk about ISBN Tables in
verbal communication and not tblIsbn. So if OO supposed to be closer to
the human thinking why not make our notation closer, too?
One more example why I feel Hungarian does not make clear sense under
C++. I give here a C and a C++ example of the same concept:
hMainWindow - a Window handle in a C program to the main window.
class MainWindow {
//...
private:
whatever mHandle;
//...
};
//... later in WinMain (what does the standard say about this???
Shouldn't it be main?)
// or in an application class:
MainWindow mainWindow( "My free UML designer v0.0beta");
// and so on
So as you see in C++ you just don't find the place, to use that h prefix
at all...
My 2cs.
Attila
John Jacob wrote:
>
> Hello,
>
> I have been using c++ for a while, and mostly developed with MFC. After a
> while, I adopted the hungarian notation, it being the style used in most
> code I had come across.
> However, I keep seeing opinions that hungarian should not be used.
> What are the actual disadvantages of hungarian? Using hungarian does not
> affect speed or stability, and does not affect the person who wrote it.
> Variable naming is done so that the NEXT person who writes finds it easier
> to understand the code.
> So, does hungarian make code harder to maintain? Does it make code more
> difficult to read?
> Are there any alternatives to hungarian - seeing that just naming variables
> at random can cause problems (e.g where a name "file" would be used in a
> single project to mean a handle to a file, a filepath, a CFile object etc.
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Alf P. Steinbach
http://www.cs.umd.edu/users/cml/cstyle/ottinger-naming.html#Avoid_Encodings
Not sure whether I agree with everything, but it's practical and
balanced.
Cheers,
- Alf
"John Jacob" <jo...@jacob.com> wrote in message
news:9ckfqe$aa0$1...@rzsun03.rrz.uni-hamburg.de...
> Hello,
>
> I have been using c++ for a while, and mostly developed with MFC. After a
> while, I adopted the hungarian notation, it being the style used in most
> code I had come across.
> However, I keep seeing opinions that hungarian should not be used.
> What are the actual disadvantages of hungarian? Using hungarian does not
> affect speed or stability, and does not affect the person who wrote it.
> Variable naming is done so that the NEXT person who writes finds it easier
> to understand the code.
> So, does hungarian make code harder to maintain? Does it make code more
> difficult to read?
> Are there any alternatives to hungarian - seeing that just naming variables
> at random can cause problems (e.g where a name "file" would be used in a
> single project to mean a handle to a file, a filepath, a CFile object etc.)
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Ron Natalie
Erik Max Francis wrote:
>
> Carlos Moreno wrote:
>
> > Just let me put the above paragraph in hungarian notation and tell me
> > if you could read it:
> >
> > IPersonallyDislikeTheHungarianConvention --
> > IFindItMuchHarderToReadThanUsing
> >
> > Compare it to this:
> >
> > I_personally_dislike_the_hungarian_convention --
> > I_find_it_much_harder_to_read ...
>
> Um, that's not Hungarian notation. Hungarian notation is when the type
> or usage of a variable is embedded in its identifier.
Encoding the type isn't Hungarian notation either. That's just the
Microsoft's bastardization of it. To make things worse, microsoft
invents non-sensical type conventions and still carries through obsolete
notions like
LPSTR
the type is neither "LONG" nor is it a "POINTER" to a "STRING".
Francis Glassborow
<Attila...@lmf.ericsson.se> writes
>Please note, that the Hungarian notation is something developed for the
>C language, and not the C++. In C, it was (is) quite simple to come up
>meaningful prefixes for the "few" types, which make sense in a
>particular domain (like Windows programming).
More precisely it was developed for a particular implementation of C. At
the time MS was developing/advocating it C only required names with
external linkage to differ in the first 6 (I think, but it might have
been 8) characters, and case was not significant. That made HN
completely unusable on some systems (yes I was bitten by limited length
identifiers when porting some code in the 1980s)
Francis Glassborow ACCU
64 Southfield Rd
Oxford OX4 1PA +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
Erik Max Francis
> Encoding the type isn't Hungarian notation either. That's just the
> Microsoft's bastardization of it.
Well, I can honestly say that I've never seen any real-world code,
anywhere, under any circumstances, that actually met the ideals that
Hungarian notation is supposed to achieve. Which is precisely one of
its chief problems.
--
Erik Max Francis / m...@alcyone.com / http://www.alcyone.com/max/
__ San Jose, CA, US / 37 20 N 121 53 W / ICQ16063900 / &tSftDotIotE
/ \ Get married, but never to a man who is home all day.
\__/ George Bernard Shaw
Erik Max Francis' bookmarks / http://www.alcyone.com/max/links/
A highly categorized list of Web links.
Neil Butterworth
news:3AF008D9...@spamcop.net...
>
>
> Erik Max Francis wrote:
> >
> > Carlos Moreno wrote:
> >
> > > Just let me put the above paragraph in hungarian notation and tell me
> > > if you could read it:
> > >
> > > IPersonallyDislikeTheHungarianConvention --
> > > IFindItMuchHarderToReadThanUsing
> > >
> > > Compare it to this:
> > >
> > > I_personally_dislike_the_hungarian_convention --
> > > I_find_it_much_harder_to_read ...
> >
> > Um, that's not Hungarian notation. Hungarian notation is when the type
> > or usage of a variable is embedded in its identifier.
>
> Encoding the type isn't Hungarian notation either. That's just the
> Microsoft's bastardization of it. To make things worse, microsoft
> invents non-sensical type conventions and still carries through obsolete
> notions like
> LPSTR
>
> the type is neither "LONG" nor is it a "POINTER" to a "STRING".
>
As Microsoft, in the shape of Charles Simonyi, _invented_ Hungarian, I don't
see how you can say they have bastardised it. And Hungarian _does_ encode
type - see the interview with Simonyi in "Programmers At Work", Microsoft
1986, ISBN 0-914845-71-3 for a particularly nasty example taken from MS
Word!
NeilB
Ron Natalie
Neil Butterworth wrote:
=
> As Microsoft, in the shape of Charles Simonyi, _invented_ Hungarian, I don't
> see how you can say they have bastardised it.
Read Synomi's original paper. Function not type! Just because he worked for
Microsnot doesn't mean that how they actually implemented it wasn't a
bastardization
of the original idea.
> And Hungarian _does_ encode
> type - see the interview with Simonyi in "Programmers At Work", Microsoft
> 1986, ISBN 0-914845-71-3 for a particularly nasty example taken from MS
> Word!
When Simonyi uses type in his paper, he defines what he means by it, and it
is different from the C/C++ definition of word. His type refers to the
allowable operations on that class of object.
Neil Butterworth
>
>
> Neil Butterworth wrote:
> =
> > As Microsoft, in the shape of Charles Simonyi, _invented_ Hungarian, I
don't
> > see how you can say they have bastardised it.
>
> Read Synomi's original paper. Function not type! Just because he worked
for
> Microsnot doesn't mean that how they actually implemented it wasn't a
> bastardization
> of the original idea.
In the interview, he speaks of using the notation to encode "properties",
which sounds more like type than function to me. And the code that he must
have provided definitely encodes type Do you have a link to the original
paper?
>
> > And Hungarian _does_ encode
> > type - see the interview with Simonyi in "Programmers At Work",
Microsoft
> > 1986, ISBN 0-914845-71-3 for a particularly nasty example taken from MS
> > Word!
>
> When Simonyi uses type in his paper, he defines what he means by it, and
it
> is different from the C/C++ definition of word. His type refers to the
> allowable operations on that class of object.
NeilB
[Moderators - the post fro me that Ron is replying to was sent over 24 hours
before it appeared in the newsgroup. When it finally appeared in the
newsgroup, Ron's reply appeared here within one hour This is not the first
time I've noticed such marked difference in response. Does where you are
posting from affect which moderation queue you end up in and thus how long
it is before your post appears here?]
{Not necessarily, but who gets the article and how busy he is when he gets
it can make a difference. For example, I get a percentage of articles
automatically sent to me for moderating, and I left that on and continued
moderating while in the C++ standards meeting in Copenhagen, which was
fine because we had a net connection there. But then last night I went
offline and travelled home today and plugged back in, leaving a 30-hour
offline window before I caught up on my part of the queue. (I didn't turn
the autosends off because it was a short offline window, though next time
perhaps I should turn them off.)
Usually my/our response time is more regular than that, of course. That
was a special case, but sometimes things come up. Offhand, I think our
usual queue length is a couple of hours, and rarely hits a day. -mod/hps}
Michael H. Manov
>The question is largely irrelevant anyway. Good programmers should be able
>to read all the popular styles for layout and naming, so it doesn't matter
>what style they write in.
Once upon a time, we at Glagolitic Software decided to use
Hungarian notation. Sadly, it got away from us, and
degenerated into what we later called Elbonian Notation.
Here is our story. Don't let this happen to you.
It all started when our chief architect said that we needed
to increase accountability in our code; to do so, each coder
would henceforth prepend his first name to each local
variable. So, we had variables such as yuriColumnIndex and
janaRowCounter. The next step in increased accountability
was to add the names of the coders' team leads. This was
implemented by adding patronymics to the existing coder's
names, leading to juanitaSergeyvichCallbackIterator and
nikitaOreillyBackInserter. So far, the inconvenience was
only modest.
The real turning point came one night when the pizza was
late and Mike (not his real name) got a bit light-headed.
In his delirium, he said "Has anyone ever really implemented
PJ Plauger's idea of writing code that can be read as
literature?". That very night, he revised our coding style
guide, directing that, as you scan the code, the variable
name prefixes should read as literature. As an example, he
showed how an uninitialized pointer should be named (the
Haiku form is optional):
char* toPointOrNotToPoint_havingAsYetNoValue_iDoNeither;
We tried to follow his direction, but the vision never became
reality. We hired a newbie C++ coder on the strength of his
being a finalist in the Edgar Bulwer-Litton Bad Fiction
contest, but he never wrote anything but Burma Shave jingles;
we had to let him go.
In the end, what was supposed to have been literature became
cubicle chatter and gossip; people talked about what they
always like to talk about. Some used their code to publicize
office misdeeds:
int joeySwipedMyTwinkiesYesterday_that_FINK = 42;
Others used their code to pursue their own personal agendas:
int swfSeeksCompanionForLongWalksOnBeach_BmwM3Helpful = 29;
One unanticipated benefit of the latter was a strong increase
in developer participation in code reviews. Ultimately, though,
the social overhead of the policy overwhelmed the software
objectives. An experiment in which we embedded advertising
{int ourEBusinessSolutionKicksBits = 1;} in our source code
product line backfired, reducing sales. As our software
functionality withered, efforts to syndicate the source
code with a local TV soap opera, "As The Mouse Wheel Turns",
collapsed.
Our once-proud business now stands on the brink of failure.
Our new Software Architect is our last hope. She has a degree
in Accounting and Business Software. Her first policy change
takes effect tomorrow: all variable names are now limited to
six characters. Brothers and Sisters, please wish us luck ...
m.
[Dear Moderator: if this is too silly to post, well, that's
OK. I had fun writing it anyway.]
P.J. Plauger
> The real turning point came one night when the pizza was
> late and Mike (not his real name) got a bit light-headed.
> In his delirium, he said "Has anyone ever really implemented
> PJ Plauger's idea of writing code that can be read as
> literature?".
Actually, I believe it was Don Knuth who promoted software as
literature. All Kernighan and I encouraged was that code should
be readable.
But I like the idea of selling advertising space within
identifiers. It might rescue a few struggling dot coms.
Thanks for an entertaining post.
P.J. Plauger
Carlos Moreno
CLAP CLAP CLAP CLAP!!!!!
BTW, whoever moderator let this post through to the newsroup...
THANK YOU, THANK YOU, THANK YOUUUUUU!!!!!!
:-)
Carlos
--
"Michael H. Manov" wrote:
>
> Once upon a time, we at Glagolitic Software decided to use
> Hungarian notation. Sadly, it got away from us, and
> degenerated into what we later called Elbonian Notation.
> Here is our story. Don't let this happen to you.
>
> [...]
L. F. Hall
>CLAP CLAP CLAP CLAP!!!!!
>BTW, whoever moderator let this post through to the newsroup...
>THANK YOU, THANK YOU, THANK YOUUUUUU!!!!!!
Agreed. It's great like the perfect COBOL program as a template
argument a few days ago. Moderator of approvals is always given.
It was 'Approved: ku...@fmi.uni-konstanz.de'.
(See File > Properties > Details on original message.)
Many thanks, also.
Len
James Kanze
> [Moderators - the post fro me that Ron is replying to was sent over
> 24 hours before it appeared in the newsgroup. When it finally
> appeared in the newsgroup, Ron's reply appeared here within one hour
> This is not the first time I've noticed such marked difference in
> response. Does where you are posting from affect which moderation
> queue you end up in and thus how long it is before your post appears
> here?]
> {Not necessarily, but who gets the article and how busy he is when he gets
> it can make a difference. For example, I get a percentage of articles
> automatically sent to me for moderating, and I left that on and continued
> moderating while in the C++ standards meeting in Copenhagen, which was
> fine because we had a net connection there. But then last night I went
> offline and travelled home today and plugged back in, leaving a 30-hour
> offline window before I caught up on my part of the queue. (I didn't turn
> the autosends off because it was a short offline window, though next time
> perhaps I should turn them off.)
> Usually my/our response time is more regular than that, of course. That
> was a special case, but sometimes things come up. Offhand, I think our
> usual queue length is a couple of hours, and rarely hits a day. -mod/hps}
It's probably worth pointing out as well that postings come to the
moderation site via email, usually through a forwarder. And delivery
times for email vary, from a couple of seconds up through a couple of
days. Or more -- I think we had one submission that had spent more
than a month in email.
--
James Kanze mailto:ka...@gabi-soft.de
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
Ziegelhüttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627
Balog Pal
news:9ckfqe$aa0$1...@rzsun03.rrz.uni-hamburg.de...
> I have been using c++ for a while, and mostly developed with MFC. After a
> while, I adopted the hungarian notation, it being the style used in most
> code I had come across.
Grrr, did I ever mention how I hate this nightmare named "hungarian" notation
what it is not?
> However, I keep seeing opinions that hungarian should not be used.
Talking about that Microsoft naming convention they dump on the innocent world
of programmers strting with the windows SDK (or maybe even before that) it is
definitely something to be banished.
> What are the actual disadvantages of hungarian?
Well, if you start using some "feature" first you must list the advantages.
Then, having a fat list you can see after the side effects. Unfortunately that
list is pretty thin for this one.
> Using hungarian does not
> affect speed or stability, and does not affect the person who wrote it.
Sure it does. It prings tremendous amount of redundancy into the source code.
And in my field experience the bigger part of the trouble comes from
redundancy.
> Variable naming is done so that the NEXT person who writes finds it easier
> to understand the code.
Did you verify that theory in practice? I find quite the opposite. Sane
programmers are very well off with meaningful identifiers, those that stick to
the content or the purpose of the thing held, not attaching any concrete type
info. Especially in C++, where most data is abstract anyway, and types may
change under the code without hurting existing behavior. (But leaving you the
problem of either adjusting the identifiers, or living with names that contain
OUTDATED type info.)
> So, does hungarian make code harder to maintain?
Definitely yes.
> Does it make code more difficult to read?
After years working with code like that ypu'll probably learn to filter the
prefixes right with your eyes, so it will not be more difficult to read IF the
rest of the identifier is good enough. However I found people actively
following M$ tend to get tired writing lpstr and run out of imagination for
rhe rest. Thus failing to provide the only interesting part.
Also, if you're using some environment, like msvc, the type is there as a
tooltip, if you're really interested.
> Are there any alternatives to hungarian - seeing that just naming variables
> at random can cause problems (e.g where a name "file" would be used in a
> single project to mean a handle to a file, a filepath, a CFile object etc.)
"file" is fefinitely a bad name (in general), and decorating it to hFile,
cfileFile, srtFile or something like that will not make it a gramm better.
howefer "inputfile" "tempfile" will be informative, and "logfilename",
"logfilepath", "logfile" will likely hold some kind of strings for the first
two, and a usable file object for the last. The type must be obvious in the
context, and not really important anyway.
Paul
Balog Pal
news:3AEFA7F7...@lmf.ericsson.se...
>
> Please note, that the Hungarian notation is something developed for the
> C language, and not the C++.
Well, let's assume that. (However the idea reads more general.)
> In C, it was (is) quite simple to come up
> meaningful prefixes for the "few" types, which make sense in a
> particular domain (like Windows programming).
Having that pesky "typedef" C has arbitrary many types too, and you can find
hundreds of thos in the Windows SDK mentioned. And mapping even that
particular subset of types to unique prefixes is not that easy as it first
sounds.
And it has hardly any usefulness outside the _printed_ code samples in a book.
:-)
[a plenty of good points cut]
> So I guess it is important for a C++ program, too, to give a good hint
> about what is the variable. But I doubt that the Hungarian notation is
> well suited for that purpose. For prefix I usually use something
> talking about the variables placement and constness, like aIsbnTable is
> an argument (non-const reference as usual) and mIsbn is a member,
> cgMaxTimers is a global constant etc.
That is another interesting thing, whether the placement of a variable should
appear in the name as provided here. Like using some pre- or postfix for data
members is very common. But just being common does not prove it is really
good. Reading code I don't have the problem to see the locals. All the rest is
then part of the state. Should we really care the placement so much to inject
in the name?
Marking arguments is something I see the first time here.
Paul
JKB
dealing
with a lot of ex-Microsoft sorts. Having worked in projects that required
Hungarian, projects that didn't, and projects that wanted to but didn't
enforce
it, I'd say it's pretty much a wash. Definitely a more-heat-than-light issue.
The simple prefixes are kind of nice. I use b and n, to mean boolean-flag and
integer-count-of-something. That's even though I'm normally the guy heckling
the
MS types about how useless hungarian is. In a webserver environment, it's
also
nice to distinguish sz (null-terminated ANSI string) from wz (also
null-terminated, but 16-bit Unicode) from str (a string object, whether MFC
CString or STL std::string).
And of course there are gross abuses. They're pretty well published, so we
don't
need to go there right now.
Biggest tangible disadvantage I know of for Hungarian is the maintenance
headache. I rename or otherwise refactor a class, and in principle I should
now
rename all the identifiers that denote instances of that class. But I don't,
because that would touch too many files and be a nightmare, and I wouldn't
find
all the instances anyway. So now I have identifiers that appear to contain a
type
prefix but in fact are wrong, which is worse than not having one at all.
The more different coding styles I see, the less merit I see in debating their
qualities. A professional programmer needs to deal with whatever customs he
encounters, including inconsistent or silly ones. I have my preferences
(obviously superior to anyone else's preferences) but it's not that important.
Having said that, Hungarian is stupid and a holdover from <expletive> x86
assembly, and should not ever be used if you want to ship before the
Apocalypse.
-- jkb
Balog Pal wrote:
> "John Jacob" <jo...@jacob.com> wrote in message
> news:9ckfqe$aa0$1...@rzsun03.rrz.uni-hamburg.de...
>
> > I have been using c++ for a while, and mostly developed with MFC. After a
> > while, I adopted the hungarian notation, it being the style used in most
> > code I had come across.
>
> Grrr, did I ever mention how I hate this nightmare named "hungarian"
notation
> what it is not?
...
Balog Pal
> The simple prefixes are kind of nice. I use b and n, to mean boolean-flag
and
> integer-count-of-something. That's even though I'm normally the guy
heckling
> the
> MS types about how useless hungarian is.
Interesting, I do exactly that. But note how that stands out fron the other
uses.
b for boolean (for me) means the content/purpose of the variable, not the
type. The type may be bool, BOOL, Boolean, somtimes int or short. But
whatever it is, having that b prefix I flag it will have one of two predefined
values.
n also is just like abbreviation for "number" or "number of". Type may be
anything capable holding counts, it may not even be necessarily integral type
(however the value probably will be.)
> In a webserver environment, it's
> also
> nice to distinguish sz (null-terminated ANSI string) from wz (also
> null-terminated, but 16-bit Unicode) from str (a string object, whether MFC
> CString or STL std::string).
And surely that is the case when the _format_ is the important information
that should be part of the identifier. It's like a warning sign. However if
all the other variables also hold such marks, it will be like having a
redundant warning every second. You'll pretty soon ignore it, and so ignore
the really important small subset with the rest.
Paul