Hungarian notation

D

dom.k.black

I am looking at starting a new piece of work for a company who are
heavily into hungarian notation for C coding.

Any killer arguments for NOT carrying this terrible practice forward
into new C++ code?
 
D

dave_mikesell

I am looking at starting a new piece of work for a company who are
heavily into hungarian notation for C coding.

Any killer arguments for NOT carrying this terrible practice forward
into new C++ code?

Variable names are like comments - they can lie. If the type of a
variable changes, you either have to hunt down every occurrence of it
to change, or allow it to fib about the type.
 
J

Jeff Schwab

I am looking at starting a new piece of work for a company who are
heavily into hungarian notation for C coding.

Any killer arguments for NOT carrying this terrible practice forward
into new C++ code?

It is anathema to generic programming. You might also consider asking a
Python group of the ways in which it would mess with duck typing.
 
A

Andrey Tarasevich

I am looking at starting a new piece of work for a company who are
heavily into hungarian notation for C coding.

Any killer arguments for NOT carrying this terrible practice forward
into new C++ code?

What kind of "hungarian notation"? If they use it to describe the exact type of
the variable, like 'li' for 'long int', 'usi' for 'unsigned short int' etc.,
then it is not so hard to find many arguments against it.

If they use some form of prefixing just to describe some aspects of the
semantics of the variable, like 'i' for ordinals, 'n' for quantities, 'p' for
high-level class pointers as opposed to 'lp' for pointers to POD structs, 'bf'
for bitwise-used variables etc., then it is not only not a "terrible practice",
but quite opposite - something worth picking up as a habit and using extensively.
 
D

dave_mikesell

If they use some form of prefixing just to describe some aspects of the
semantics of the variable, like 'i' for ordinals, 'n' for quantities, 'p' for
high-level class pointers as opposed to 'lp' for pointers to POD structs, 'bf'
for bitwise-used variables etc., then it is not only not a "terrible practice",
but quite opposite - something worth picking up as a habit and using extensively.

Disagree. It's just another convention to learn. How is
nNumPolygons more descriptive than NumPolygons? And it almost forces
the use of CamelCase, which hurts my eyes.
 
D

dom.k.black

What kind of "hungarian notation"? If they use it to describe the exact type of
the variable, like 'li' for 'long int', 'usi' for 'unsigned short int' etc.,
then it is not so hard to find many arguments against it.

They use it to *precisely* encode the type, if it is a const pointer
to an unsigned short you can tell it from the prefix...
If they use some form of prefixing just to describe some aspects of the
semantics of the variable, like 'i' for ordinals, 'n' for quantities, 'p' for
high-level class pointers as opposed to 'lp' for pointers to POD structs, 'bf'
for bitwise-used variables etc., then it is not only not a "terrible practice",
but quite opposite - something worth picking up as a habit and using extensively.

Well I have to part agree, part disagree. Ad hoc use of prefixes can
sometimes make the code easier to follow, as can good names in
general. eg using x and y as prefixes *within a particular class* if
you have quantities which relate to x and y axes.

Forcing people to classify every variable as an ordinal or quantity or
whatever is less useful, imho, and if a variable is a pointer it is
usually obvious from the -> which follow it. These less useful
prefixes get in the way if there are cases where an ad hoc prefix
might be useful.

As a habit, as opposed to a dictat, well it isn't something I would
do, but each to their own.
 
A

Andrey Tarasevich

> On Mar 21, 10:16 am, Andrey Tarasevich <[email protected]>
> wrote:
> extensively.
>
> Disagree. It's just another convention to learn.

There's _always_ a convention. Certain aspects of the variable semantics have to
be reflected in variable name. That's what variable names are for, among other
things. If you don't do it at all or do it inconsistently (without any
convention), your code isn't worth much in my book.

Prefixing is no worse and no better than anything else.
> How is
> nNumPolygons more descriptive than NumPolygons?

Bad example. It is not more descriptive because in 'nNumPolygons' you used two
"conventions" at once. Prefix 'n' and prefix 'Num'. What's funny is that while
trying to bash prefixes you used just another prefix yourself! Which is
essentially the same as "hungarian notaion".

The proper name of the variable to store a quantity of polygons is 'n_polygons'.
And no CamelCase, as you see.
 
D

dom.k.black

There's _always_ a convention. Certain aspects of the variable semantics have to
be reflected in variable name. That's what variable names are for, among other
things. If you don't do it at all or do it inconsistently (without any
convention), your code isn't worth much in my book.

Prefixing is no worse and no better than anything else.

The problem with prefixing is that it forces you to encode particular
facts about the variable, right at the start of its name. Even if
those particular facts are not relevant or important in the context.

In addition, the information is encoded in a single character and you
have to know what that character means.
Bad example. It is not more descriptive because in 'nNumPolygons' you used two
"conventions" at once. Prefix 'n' and prefix 'Num'. What's funny is that while
trying to bash prefixes you used just another prefix yourself! Which is
essentially the same as "hungarian notaion".

The proper name of the variable to store a quantity of polygons is 'n_polygons'.
And no CamelCase, as you see.

There is nothing "proper" about n_polygons as opposed to NumPolygons,
and the latter is actually clearer to the general reader. This is an
ad hoc prefix, and it can highlight whatever aspect of the variable
meaning that the developer feels is most useful to highlight.

It is better to be consistent (ie don't use Num, NumberOf and n in
different bits of the code) - but how important that is in absolute
terms I am not sure.
 
A

Andrew Koenig

I am looking at starting a new piece of work for a company who are
heavily into hungarian notation for C coding.

Then your best course of action is probably to follow the golden rule: The
people with the gold make the rules.

Take the view that they can't waste your time -- they can only waste their
money.
Any killer arguments for NOT carrying this terrible practice forward
into new C++ code?

Yes there are, but the company isn't paying you to convince them.

Here are two arguments:

1) Hungarian notation requires you to repeat the same information (the
type of a variable) every time you use the variable. We've already been
down that road in assembly languages, which encode the type of an operand in
every instruction that uses the operand. Therefore, the disadvantages of
that approach should be well enough known that it would be unnecessary to
repeat them. Just as one example: If you ever change your mind about the
type of a variable, you have to change every piece of code that uses that
variable.

2) What if you don't know the type of a variable when you write the
program? This happens all the time in generic programs.

If you can make these arguments successfully, more power to you. But I am
serious when I suggest that you tread carefully, because they're not paying
you to convince them.
 
B

Bo Persson

They use it to *precisely* encode the type, if it is a const pointer
to an unsigned short you can tell it from the prefix...

But in C++ it generally isn't a pointer to an unsigned short, it is a
reference to an object of some class type. If you try to assign it a
value of an incompatible class type, the compiler will tell you.


Bo Persson
 
D

dave_mikesell

Bad example. It is not more descriptive because in 'nNumPolygons' you used two
"conventions" at once. Prefix 'n' and prefix 'Num'. What's funny is that while
trying to bash prefixes you used just another prefix yourself! Which is
essentially the same as "hungarian notaion".

The proper name of the variable to store a quantity of polygons is 'n_polygons'.
And no CamelCase, as you see.

I'm not bashing prefixes, just ambiguous single letter prefixes that
require knowledge of some homegrown convention. I could have as
easily used polygon_count or total_polygons.
 
A

Andrey Tarasevich

They use it to *precisely* encode the type, if it is a const pointer
to an unsigned short you can tell it from the prefix...

Well, the problem is that anything that is a "killer argument" against
it for me, for example, quite likely might not work as a killer argument
for those who establish these rules in your case. Simply because they
might not (care to) see things the way I or you do.

I believe that the code is supposed to be as abstracted as possible form
the concrete types of the variables it operates on (with the exception
of the most low-level platform-specific one). The obvious example of the
need for such abstraction is template code, and it was mentioned here
more than once already, but in fact this applies in no lesser degree to
"regular" (non-template) code as well. Encoding the exact variable type
in the variable name is breaking this abstraction.

That would make a "killer argument" for me. YMMV.

On the other hand, encoding the algorithm-specific variable semantics in
the variable name is not breaking the aforementioned abstraction.
Forcing people to classify every variable as an ordinal or quantity or
whatever is less useful, imho, and if a variable is a pointer it is
usually obvious from the -> which follow it.

I'd say that in my opinion in this case you got it a bit backwards. It
is the variable semantics (which can be encoded in the name) that is
supposed to suggest the proper uses for that variable, not the other way
around.

For example, in my code an integral variable prefixed with 'bf_...' is
supposed to be used as an ad-hoc bit-field used with bitwise operations.
Using '<' or '+' on such variable would be an immediately obvious error.

Note, BTW, that in cases like that most programmers do naturally feel
the urgent need to encode this property in the variable name by
including "keywords" like 'flags' or 'modes' in the variable name. I use
the 'bf_' prefix for the very same purpose and try to avoid redundancy
(i.e. if it is 'bf_...' there's no need to additionally describe it as
'..._flags').
 
J

Jeff Schwab

Disagree. It's just another convention to learn. How is
nNumPolygons more descriptive than NumPolygons? And it almost forces
the use of CamelCase, which hurts my eyes.

Agreed on both counts. (CamelCase isn't innately evil, but trying to
mix CamelCase and snake_case libraries has been a generally unpleasant
experience for me.)

Hungarian notation is useful for encoding static type-related
information in a human-readable form. I've found it useful in assembly
language ("is that integer signed or unsigned?"). Joel Spolsky gives a
good example, based on his experience with JavaScript:

http://www.joelonsoftware.com/articles/Wrong.html

In C++, the generally correct solution is to encode static type-related
information directly into the types themselves. Given a variable
nNumPolygons, the best solution probably is to change it to NumPolygons
(which encodes abstract meaning in a human-readable fashion), and to
encode whatever "n" means into a static type that cannot be directly
converted to any incompatible type.
 
A

Andy Champ

Andrew said:
Then your best course of action is probably to follow the golden rule: The
people with the gold make the rules.

Take the view that they can't waste your time -- they can only waste their
money.


Yes there are, but the company isn't paying you to convince them.

Here are two arguments:

1) Hungarian notation requires you to repeat the same information (the
type of a variable) every time you use the variable. We've already been
down that road in assembly languages, which encode the type of an operand in
every instruction that uses the operand. Therefore, the disadvantages of
that approach should be well enough known that it would be unnecessary to
repeat them. Just as one example: If you ever change your mind about the
type of a variable, you have to change every piece of code that uses that
variable.

2) What if you don't know the type of a variable when you write the
program? This happens all the time in generic programs.

If you can make these arguments successfully, more power to you. But I am
serious when I suggest that you tread carefully, because they're not paying
you to convince them.
*The* Koenig?

Can I add another argument:

What is the correct Hungarian notation for a variable of type

std::vector<std::list<MyClassYouDoNotKnowWHatItDoes> >

I also think that syntax colouring and Microsoft's Intellisense (I
assume other systems have something similar) mean that a lot of the
problems it was meant to deal with are no longer relevant.

Sorry, Dr Simonyi!

The Wikipedia article

http://en.wikipedia.org/wiki/Hungarian_notation

Has some points too.

Andy
 
A

Andrey Tarasevich

Jeff said:
...
Hungarian notation is useful for encoding static type-related
information in a human-readable form. I've found it useful in assembly
language ("is that integer signed or unsigned?"). Joel Spolsky gives a
good example, based on his experience with JavaScript:

http://www.joelonsoftware.com/articles/Wrong.html

In C++, the generally correct solution is to encode static type-related
information directly into the types themselves. Given a variable
nNumPolygons, the best solution probably is to change it to NumPolygons
(which encodes abstract meaning in a human-readable fashion), and to
encode whatever "n" means into a static type that cannot be directly
converted to any incompatible type.

What Joel says in his article agrees precisely with what I said so far.
Application/semantics-oriented variable name prefixing is a useful technique.
Moreover, according to what he says in the linked article, this was in fact the
original intended use of Hungarian notation. The strange habit of encoding exact
type information in variable prefix was "invented" by someone later and for some
unexplainable reason this strange and largely useless approach to variable name
prefixing has become associated with "hungarian notation", while in fact it was
never intended to be used that way.

For this reason it is rather strange to see you, after referring to the above
article, to contradict it right away by referring to 'n' in 'nNumPolygons' as
something that has to be encoded into a static type. In the original Hungarian
notation concept, 'n' means exactly what 'Num' means, meaning that the 'Num'
part is redundant and the proper name within the concept of original Hungarian
notation is supposed to look as, for example, 'nPolygons'. Or 'numPolygons' if
you prefer to use prefix 'num' for ordinals. I, for one, would still stick with
'n' because it's shorter but its meaning is still immediately, naturally and
intuitively understandable. And no, for this very reason it doesn't require
remembering any "homegrown conventions", just like pretty much any other
thoughtfully chosen prefix. It is especially funny to see 'n' being criticized
by several posters in this thread, when it is actually widely used as a short
designator of "quantity" virtually everywhere by virtually everyone.
 
J

Jeff Schwab

Andrey said:
What Joel says in his article agrees precisely with what I said so far.
Application/semantics-oriented variable name prefixing is a useful
technique. Moreover, according to what he says in the linked article,
this was in fact the original intended use of Hungarian notation. The
strange habit of encoding exact type information in variable prefix was
"invented" by someone later and for some unexplainable reason this
strange and largely useless approach to variable name prefixing has
become associated with "hungarian notation", while in fact it was never
intended to be used that way.

For this reason it is rather strange to see you, after referring to the
above article, to contradict it right away by referring to 'n' in
'nNumPolygons' as something that has to be encoded into a static type.
In the original Hungarian notation concept, 'n' means exactly what 'Num'
means,

Leading lowercase n has meant "unsigned integer" everywhere I've ever
seen it used.
meaning that the 'Num' part is redundant and the proper name
within the concept of original Hungarian notation is supposed to look
as, for example, 'nPolygons'. Or 'numPolygons' if you prefer to use
prefix 'num' for ordinals. I, for one, would still stick with 'n'
because it's shorter but its meaning is still immediately, naturally and
intuitively understandable.

Not to me, it isn't. You're going to have an up-hill battle trying to
redefine a de facto standard prefix on the grounds that it saves two
characters.
And no, for this very reason it doesn't
require remembering any "homegrown conventions", just like pretty much
any other thoughtfully chosen prefix. It is especially funny to see 'n'
being criticized by several posters in this thread, when it is actually
widely used as a short designator of "quantity" virtually everywhere by
virtually everyone.

Huh? That's not what it means... When you say "virtually everywhere by
virtually everyone," where and whom exactly are you talking about?
 
A

Andrey Tarasevich

Jeff said:
Leading lowercase n has meant "unsigned integer" everywhere I've ever
seen it used.

Hm... I don't really see how it is relevant. All you are saying here is that
every time you saw prefixed variable names in use, the technique was used
incorrectly. I do feel sorry for you. My experiences were more varied: I saw
improper uses of prefixes and misguided attempts at Hungarian notation, but I
also saw the proper uses as well. More importantly, what I care most about is I
personally use it properly.
Not to me, it isn't. You're going to have an up-hill battle trying to
redefine a de facto standard prefix on the grounds that it saves two
characters.

What "de-facto standard"? There's no "de-facto standard" of using 'num' instead
of 'n'.

If you are referring to 'n' being de-facto associated with 'unsigned int' by
those who insist on broken approach to Hungarian notation, I don't really care
about fighting any battles here. This case has already been debated extensively
and exhaustively, solved and closed for good. Any person that continues to
blindly insist on using distorted and useless approach to name prefixing is not
really worth my time to fight with.
Huh? That's not what it means... When you say "virtually everywhere by
virtually everyone," where and whom exactly are you talking about?

Virtually every person who ever wrote C/C++ code and virtually every piece of
code ever written by these people. I don't understand how I can describe it in
any other way.

For example, I don't think the authors of C and C++ standard documents ever
worried about the appropriateness of using 'n' to designate quantities (as
opposed to, say, 'num' or 'count').
 
P

Paul Brettschneider

Jeff said:
Leading lowercase n has meant "unsigned integer" everywhere I've ever
seen it used.

Leading lowercase n has always just meant "number of" for me.
And apparently I'm not the only one, as you can for example see
in /usr/include/postgresql/libpq-fe.h:
extern int PQntuples(const PGresult *res);
extern int PQnfields(const PGresult *res);
 
D

dom.k.black

Leading lowercase n has always just meant "number of" for me.
And apparently I'm not the only one, as you can for example see
in /usr/include/postgresql/libpq-fe.h:
extern int PQntuples(const PGresult *res);
extern int PQnfields(const PGresult *res);

I've been programming in C and C++ for more than 20 years, I've worked
in many different teams and companies, I've used many 3rd party
libraries. I don't particularly recall seeing prefix n used in this
way (I probably have seen it, but not so prevelently thst it sticks in
my mind). I would always use num rather than n.

That is not to say that it isn't used commonly in other circles (the
previous poster showed 2 examples so it must be true), but it is
certainly not universal.

Point is you cannot assume that a single letter prefix is going to be
immediately obvious to everyone. My initial reaction to seeing
nPolygons would probably be to assume that n indicated a type rether
than "number of".
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top