opinions on hungary notation

[Serve La]

I would like to start a discussion on hungary notation. What are pros, what
are cons? Best use them or not?

 

[Leo Havmøller]

I would like to start a discussion on hungary notation. What are pros,
what are cons? Best use them or not?

Joel Spolsky has an excellent article (as always) about it:
http://www.joelonsoftware.com/articles/Wrong.html
Some historical information is almost at the bottom, under the "I'm Hungay"
headline.

Leo Havmøller.

 

[Serve La]

Serve La said:


Hungarian Notation can mean at least two different things - a fairly
sensible naming convention, or a mindless prefixing of types to
identifiers (which means you have to go back and change all instances
of an identifier usage if its type changes, or else make an even
bigger mockery of the whole thing).

Which of those would you like to discuss?

The mindless type prefixing yes. I was under the impression that the
hungarian type prefixing was seen as pretty useless nowadays but at work
people want to introduce a coding guideline that forces us to use hungarian.
I pointed them to joel´s article already but it didnt convince them. Are
there actual advantages to using hungarian?

 

[John Bode]

The mindless type prefixing yes.  I was under the impression that the
hungarian type prefixing was seen as pretty useless nowadays but at work
people want to introduce a coding guideline that forces us to use hungarian.
I pointed them to joel´s article already but it didnt convince them. Are
there actual advantages to using hungarian?

Names should denote usage, not type. Using Hungarian notation to
encode primitive type information in a variable name is worse than
useless; it hinders readability, and it can potentially cause
maintenance headaches when you decide to change a variable's type.

However, there is some information that's potentially worth encoding
in the variable name using a Hungarian-style notation, such as whether
the variable is global, or volatile, or static. Knowing that
potentially affects where and when I use that variable (I don't want
to use static variable in a function that needs to be reentrant, for
example). The JOS article linked above shows what I consider a
reasonable use for such a naming standard.

Given my druthers, though, I'd rather not use Hungarian-style notation
at all.

 

[Serve La]

Type hungarian is problematic. I suppose it
saves looking up declarations and from time to time it may alert
the reader that something funny is going on.

Yeah thats an advantage, but the type is almost never important when reading
code. I dont need the type get thrown in my face every single time

 

[Guest]

| I would like to start a discussion on hungary notation. What are pros, what
| are cons? Best use them or not?

Including types in the names of variables sometimes helps. But not always.
Sometimes it creates more of a burden, both for development and maintenance.

More verbose names sometimes help. Sometimes they hurt, too. Where code is
getting more complex, and structurally reads better with longer lines, then
shorter variables help. I've found that there is some approximation that
variables used over a smaller scope can be shorter in name length, and those
used over a larger scope might be better to have a longer name length.

I tend to treat things more on a case by case basis, too. I do not use a
rigid coding style. If something is easier to read in a variation, I'll
do that. There are a lot more aspects of style (that people either love or
hate my code for) than the information included in variable names.

OneThingIHateALotIsVariableNamesThatAreCapitalizedAndJammedTogether. I find
those to be among the hardest to read, completely undoing any other advantages
they may have by other aspects such as type prefixes.

 

[Guest]

| Using apps hungarian has advantages. Many years I read a paper
| about measurements of productivity improvements and lowered error
| rates produced by using predefined, standardized abbreviations.
| That makes sense. Type hungarian is problematic. I suppose it
| saves looking up declarations and from time to time it may alert
| the reader that something funny is going on. In prehistoric
| fortran integers started with one set of letters and floating
| point variables started with another set. Apparently the type
| hungarians believe that fortran didn't go far enough.

If the only types you had were integer and floating point, the Fortran
convention was adequate. Today even Fortran has more types.

 

[Guest]

| "Richard Harter" <[email protected]> schreef in bericht
| |>>The mindless type prefixing yes. I was under the impression that the
|>>hungarian type prefixing was seen as pretty useless nowadays but at work
|>>people want to introduce a coding guideline that forces us to use
|>>hungarian.
|>>I pointed them to joel´s article already but it didnt convince them. Are
|>>there actual advantages to using hungarian?
|>>
|>
|> Type hungarian is problematic. I suppose it
|> saves looking up declarations and from time to time it may alert
|> the reader that something funny is going on.
|
| Yeah thats an advantage, but the type is almost never important when reading
| code. I dont need the type get thrown in my face every single time

What I consider important is what the variable relates to. Is it a number of
pixels on your Facebook wall? Is it the change in number of millimeters
between Earth and moon per year? Is it the number of nanoseconds since the
Bolshevik Revolution? Basic names give the context. Some common prefixes
or suffixes can give units.

I have wanted a nice way to tell between integer and float in a few cases.
Sometimes I keep both at the same value, using the integer to control the
loop and the float to get involved with the calculation, to avoid doing a
conversion when I could just add. That does give me two names to deal with.
I then add a suffix to keep them distinct, usually _i and _f for simplicity.

 

[osmium]

Er, yes, I believe most of us know that. The point of my heavy
handed irony was that the notion of using a naming convention to
indicate types is an ancient one that has been tried and
abandoned more than once.

Long experience tells me that irony and its cousin, sarcasm, do not mix well
with Usenet.

 

[Guest]

| On 30 Aug 2009 07:22:01 GMT, (e-mail address removed) wrote:
|
|>
|>| Using apps hungarian has advantages. Many years I read a paper
|>| about measurements of productivity improvements and lowered error
|>| rates produced by using predefined, standardized abbreviations.
|>| That makes sense. Type hungarian is problematic. I suppose it
|>| saves looking up declarations and from time to time it may alert
|>| the reader that something funny is going on. In prehistoric
|>| fortran integers started with one set of letters and floating
|>| point variables started with another set. Apparently the type
|>| hungarians believe that fortran didn't go far enough.
|>
|>If the only types you had were integer and floating point, the Fortran
|>convention was adequate. Today even Fortran has more types.
|
| Er, yes, I believe most of us know that. The point of my heavy
| handed irony was that the notion of using a naming convention to
| indicate types is an ancient one that has been tried and
| abandoned more than once.

But it was not abandoned for being a failure. It was abandoned for being
inadequate for our advances.

 

[lawrence.jones]

What I consider important is what the variable relates to. Is it a number of
pixels on your Facebook wall? Is it the change in number of millimeters
between Earth and moon per year? Is it the number of nanoseconds since the
Bolshevik Revolution? Basic names give the context.

And *that* is what Simonyi meant by "type": not the surface type like
int or unsigned long, but the deep semantic type. And his premise was
that the variable's name should *be* that "type", not some other name
with the type as a prefix. Prefixes were for derived types like pointer
to or array of. In the rare case where you need multiple variables of
the same "type" in the same scope, you can use suffixes to distinguish
(e.g., rowOld and rowNew), but his thesis was that well written code
rarely needs that.

 

[Nick Keighley]

"Richard Harter" <[email protected]> schreef in berichtnews:[email protected]...


Yeah thats an advantage, but the type is almost never important when reading
code. I dont need the type get thrown in my face every single time

the one time I've been tempted is when using C++ magic pointers.

I like to know if I've got a counted pointer (keeps count of how
many pointers there are and deletes the object when the count goes to
zero)
or an "auto" pointer (ownership is transferred between pointers) or a
whatever pointer. These I tag so I know who's supposed to delete it
and
when.

SharedPointer objectSP;
AutoPointer objectAP;

Languges with dynamic typeing seem to encourage you (or me anyway)
to use names that say what I expect their type to be. At least in
formal
parameter lists anyway.


--
smart pointers are no picnic, as are virtually all
automatic devices with something like "smart",
"simple" or "fast" in their name.
(C++ Frequently Questioned Answers (FQA))

cf. SMTP, SNMP

 

[Nick Keighley]

Personally speaking, I abandoned it because it was a failure.

I decided declaring my variables even in Fortran was just a good idea.

 

[Keith Thompson]

I suppose everyone has their own definition of failure. My
impression is that it was abandoned because it got in the way of
using meaningful names. However the real gotcha is that
inadvertently failing to declare a variable was not an error - as
a result you got the predefined type instead of what you
intended. Hungarian notation has the opposite problem - there is
nothing in the language to ensure that the type in the name
matches the type in the declaration.

I wonder if there are lint-like tools that check for consistent
Hungarian notation.

 

[REH]

OneThingIHateALotIsVariableNamesThatAreCapitalizedAndJammedTogether.  I find
those to be among the hardest to read, completely undoing any other advantages
they may have by other aspects such as type prefixes.

That's called "camel hump." I alternate between loving and hating it
(currently set to hating).

REH

 

[Keith Thompson]

That's called "camel hump." I alternate between loving and hating it
(currently set to hating).

The usual term is "camel case" or "CamelCase". A more common version
uses lower case for the first letter: "camelCase".

 

[cognacc]

The usual term is "camel case" or "CamelCase".  A more common version
uses lower case for the first letter: "camelCase".

CamelCase for types(ie. class), and camelCase for variables, seems to
be very popular.


mic

 

[REH]

CamelCase for types(ie. class), and camelCase for variables, seems to
be very popular.

mic

VxWorks uses the later for functions, and other global symbols.

REH

 

[Phil Carmody]

smart pointers are no picnic, as are virtually all
automatic devices with something like "smart",
"simple" or "fast" in their name.
(C++ Frequently Questioned Answers (FQA))

cf. SMTP, SNMP

Compare 'Democratic' in country names.
Ditto 'premium' in beer names.

Phil

 

[Richard Bos]

Compare 'Democratic' in country names.
Ditto 'premium' in beer names.

Nah, "premium" in beer names is usually correct, if you take the
original meaning of "premium": ill-gained lucre.

Richard