Hungarian notation

[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?

[dave_mikesell]

On Mar 21, 8:02*am, [e-mail] wrote:

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.

[Jeff Schwab]

do*********@googlemail.com wrote:

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.

[dave_mikesell]

On Mar 21, 4:31 pm, Andy Champ <[e-mail]:

Andrew Koenig wrote:

<snip>

*The* Koenig?

And he ain't the only C++ celeb that lurks here...

http://tinylink.com/?xUpZmTcf1j

[James Kanze]

On 21 mar, 14:06, [e-mail] wrote:

On Mar 21, 8:02 am, [e-mail] wrote:

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.

If the semantics of the variable changes, you'll want to do this
anyway.

The main argument against Hungarian notation as it generally
seems to be used is that it is pure obfuscation. In C or in
C++.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[dave_mikesell]

On Mar 22, 11:06 am, James Kanze <[e-mail]:

On 21 mar, 14:06, [e-mail] wrote:

On Mar 21, 8:02 am, [e-mail] wrote:

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.

If the semantics of the variable changes, you'll want to do this
anyway.

Semantics sure, but not type. If I use HN and my char * changes to a
CString or a std::string, I've got to change lpszFirstName to
strFirstName. Not the case if I just call it firstName.

[James Kanze]

On 22 mar, 04:23, Jeff Schwab <[e-mail]:

Andrey Tarasevich wrote:

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

The only place I've seen it use has been Fortran. Where a
leading i,j,k,l,m or n means signed integer.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[James Kanze]

On 21 mar, 17:51, "Andrew Koenig" <[e-mail]:

<[e-mail] in message

news:b2**********************************@i7g2000p rf.googlegroups.com...

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.

That's the engineer talking, not the scientist:-).

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Jeff Schwab]

James Kanze wrote:

On 22 mar, 05:02, Andrey Tarasevich <[e-mail]>

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

There are several "standards": Merriam-Webster gives both
"count" and "number of", for example. From what I've seen, n
was well established in Fortran, and was used somewhat in the
early days of C (when external symbols were only distinctive in
the first eight characters), and num seems to have been wide
spread in Cobol. But there's absolutely no reason to not use
the real standard (i.e. Merriam-Webster, for US English) in
modern C++.

I'm generally with you on this one. I've recently been using
getNumElements for syntactic compatibility with a third-party library,
but I find it vaguely jarring for several reasons. I've even started
wrapping it in an overloaded size() method, so that:

size(some_container)

works regardless of whether the container is a std::vector or one of the
other library's container types.

But I don't think I'd take the standard as a good example with
regards to naming conventions. (Witness std::remove.)

It's certainly not perfect. I still try to follow the standard
library's lead wherever feasible, but I'd like to see a few changes in
the long run. For now, I'm busy digesting the upcoming syntactic
changes in the core language, and trying to get more familiar with the
newly added library features.

James, I know you've said before that the standard library does one
thing, but that code is different. How do you keep the code compatible?
If your type names begin with capital letters, how do you use an
algorithm that expects a C::iterator rather than a C::Iterator?

[James Kanze]

On 22 mar, 19:53, Jeff Schwab <[e-mail]:

[...]

But I don't think I'd take the standard as a good example with
regards to naming conventions. (Witness std::remove.)

It's certainly not perfect. I still try to follow the standard
library's lead wherever feasible, but I'd like to see a few changes in
the long run. For now, I'm busy digesting the upcoming syntactic
changes in the core language, and trying to get more familiar with the
newly added library features.

James, I know you've said before that the standard library
does one thing, but that code is different. How do you keep
the code compatible? If your type names begin with capital
letters, how do you use an algorithm that expects a
C::iterator rather than a C::Iterator?

Define both of them:-).

Seriously, templates do cause problems, and require some
thought. Before the standard library came along, for example,
all of my containers had a function iterator(), which returned a
GoF style iterator. I've seens worked out the necessary
techniques so that most of my iterators are both GoF type
iterators and ForwardIterators in the sense of the STL, but the
name of the function is a real problem---I can't effectively
change it without breaking a great deal of existing code, and
even if I could, what other name would be reasonable.

Luckily, for the most part, if you follow the philosophy of the
STL, anything involving templates and sequences uses iterators,
and not containers, so the name collision in the container
itself hasn't turned out to be a major problem.

More generally, of course, I do often have to ask myself which
is better. Should my XDR streams be called
ixdrstream/oxdrstream, or XDRInputStream/XDROutputStream. Given
that they're very closely modeled on iostream. And what about
my streambuf decorators (currently FilteringInputStreambuf and
FilteringOutputStreambuf).

(BTW: I use CamelCase because that's what all of my customers
have used. That's not really the issue here: you could pose the
question in terms of xdr_input_stream and xdr_output_stream just
as well.)

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Yannick Tremblay]

In article <b2**********************************@i7g2000prf.g ooglegroups.com>,
<do*********@googlemail.comwrote:

>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 about trying Argument by Ridicule:

http://www.drdobbs.com/cpp/184403804

Conversations: Hungarian wartHogs
Jim Hyslop and Herb Sutter

:-)

[Andrey Tarasevich]

Yannick Tremblay wrote:

What about trying Argument by Ridicule:

http://www.drdobbs.com/cpp/184403804

Conversations: Hungarian wartHogs
Jim Hyslop and Herb Sutter

A rather prominent example of two well-recognized people engaging in
deliberate demagogy. It is interesting to note that they do seem to
understand the true meaning of the term "hungarian notation" since they
do touch it briefly at the beginning of the article (null-terminated
string example) and they also link the original article on "hungarian
notation".

However, once started, they quickly and quietly turn to deceiving the
reader by falsely presenting some ridiculous type encoding technique as
"hungarian notation". This demagogic technique is called "straw man
argument". An inexperienced reader will not notice the switch and indeed
might perceive the article as a valid argument against the notation,
while in fact it has nothing to do with it.

Note that they also use the same obviously false argument that the
change of variable type will trigger the need to change the variable
name in cases when "hungarian notation" is used - a dead giveaway that
they either have no idea what "hungarian notation" is (unlikely) or
(likely) deliberately pretend to have no idea.

Why are they doing this? I don't know. Probably just having fun.

--
Best regards,
Andrey Tarasevich

[dave_mikesell]

On Mar 27, 2:21 pm, Andrey Tarasevich <[e-mail]>
wrote:

However, once started, they quickly and quietly turn to deceiving the
reader by falsely presenting some ridiculous type encoding technique as
"hungarian notation". This demagogic technique is called "straw man
argument".

Maybe, but there were enough legitimate arguments in this thread to
hopefully rid the world of the scourge of HN.

[Krice]

On 28 maalis, 02:14, [e-mail] wrote:

Maybe, but there were enough legitimate arguments in this thread to
hopefully rid the world of the scourge of HN.

I find HN useful in enums:

enum Dwarf_Professions {dwFIGHTER=1, dwHUNTER, dwROGUE, dwMINER,
dwARCHER, dwROCKTHROWER, dwMAX_PROF};

enum Goblin_Professions {goBARBARIAN=1, goFIGHTER, goHUNTER, goROGUE,
goTINKER, goMINER, goSHAMAN, goMAX_PROF};

How else could you make difference between goblin and dwarf
professions?

[dave_mikesell]

On Mar 28, 1:13*pm, Krice <[e-mail]:

On 28 maalis, 02:14, [e-mail] wrote:

Maybe, but there were enough legitimate arguments in this thread to
hopefully rid the world of the scourge of HN.

I find HN useful in enums:

enum Dwarf_Professions {dwFIGHTER=1, dwHUNTER, dwROGUE, dwMINER,
dwARCHER, dwROCKTHROWER, dwMAX_PROF};

enum Goblin_Professions {goBARBARIAN=1, goFIGHTER, goHUNTER, goROGUE,
goTINKER, goMINER, goSHAMAN, goMAX_PROF};

How else could you make difference between goblin and dwarf
professions?

DWARF_ and GOBLIN_? The instant I saw "dw", I thought "double word".
Why use a cryptic two letter abbrev when you can use a more
descriptive word?

[Krice]

On 28 maalis, 20:16, [e-mail] wrote:

Why use a cryptic two letter abbrev when you can use a more
descriptive word?

You have a point there. I guess HN is more nerdy.

[LR]

Krice wrote:

On 28 maalis, 02:14, [e-mail] wrote:

>Maybe, but there were enough legitimate arguments in this thread to
hopefully rid the world of the scourge of HN.

I find HN useful in enums:

enum Dwarf_Professions {dwFIGHTER=1, dwHUNTER, dwROGUE, dwMINER,
dwARCHER, dwROCKTHROWER, dwMAX_PROF};

enum Goblin_Professions {goBARBARIAN=1, goFIGHTER, goHUNTER, goROGUE,
goTINKER, goMINER, goSHAMAN, goMAX_PROF};

How else could you make difference between goblin and dwarf
professions?

How about this?

struct Dwarf {
enum Profession {
FIGHTER=1, HUNTER, ROGUE, MINER,
ARCHER, ROCKTHROWER, MAX_PROF};
};

struct Goblin {
enum Profession {
BARBARIAN=1, FIGHTER, HUNTER, ROGUE,
TINKER, MINER, SHAMAN, MAX_PROF};
};

LR

[=?UTF-8?B?RXJpayBXaWtzdHLDtm0=?=]

On 2008-03-28 20:27, LR wrote:

Krice wrote:

>On 28 maalis, 02:14, [e-mail] wrote:

>>Maybe, but there were enough legitimate arguments in this thread to
hopefully rid the world of the scourge of HN.

I find HN useful in enums:

enum Dwarf_Professions {dwFIGHTER=1, dwHUNTER, dwROGUE, dwMINER,
dwARCHER, dwROCKTHROWER, dwMAX_PROF};

enum Goblin_Professions {goBARBARIAN=1, goFIGHTER, goHUNTER, goROGUE,
goTINKER, goMINER, goSHAMAN, goMAX_PROF};

How else could you make difference between goblin and dwarf
professions?

How about this?

struct Dwarf {
enum Profession {
FIGHTER=1, HUNTER, ROGUE, MINER,
ARCHER, ROCKTHROWER, MAX_PROF};
};

struct Goblin {
enum Profession {
BARBARIAN=1, FIGHTER, HUNTER, ROGUE,
TINKER, MINER, SHAMAN, MAX_PROF};
};

Drop the all-caps and it is quite good, personally I would have liked
the enumerators to be scoped so you would have have to play with a
struct/namespace. Luckily this will be in the next standard.

--
Erik Wikström

[Krice]

On 29 maalis, 18:49, Andy Champ <[e-mail]:

the other problem is what is the correct name for the Dwarf
version of the spell "ROCKTHROWER"? dw isn't enough to
distinguish them. So you end up with dwprROCKTHROWER and
dwweROCKTHROWER.

What spell?:) No I don't end up with dwpr or dwwe or anything
else than those enums.