Worse than Hungarian notation?

[Ronald S. Cook]

I'm an old Hungarian (e.g. "clsSystem") fan that came reluctantly to the
other side.

I was told how it was no longer needed since one could just mouse over a
term to see the type.

However, for various reasons, everywhere in our new project the type is
appended to the object name (e.g. "SystemClass").

I definitely think something is needed because so many of our words are
reserved keywords anyway, but doesn't this make the argument against
Hungarian moot?

I do understand that Hungarian requires all developers to know the 3-char
prefix for every type, but the trade-off is all that wordiness when the type
is put as a suffix.

Thanks for any feedback,
Ron

 

[Jeroen Mostert]

I'm an old Hungarian (e.g. "clsSystem") fan that came reluctantly to the
other side.

I was told how it was no longer needed since one could just mouse over a
term to see the type.

That's not the argument I (or all the other anti-Hungarians of the first
hour) would have used against it, but whatever works for modern times.

However, for various reasons, everywhere in our new project the type is
appended to the object name (e.g. "SystemClass").

Ah, reverse Hungarian. Tell your colleagues to stop that nonsense. A
class should not end in "Class", unless it actually *describes* a class
(i.e. is a metaclass), and I don't think you'll see many of those in your
projects, since .NET already has Type and the like.

I definitely think something is needed because so many of our words are
reserved keywords anyway,

Then prepend them with @. That's what it's there for. In my code, I often
have to use variables named "operator", but, of course, that's also a
keyword. Rather than contrive some roundabout name that wouldn't be half as
clear (because "operator" is just the accepted term in the world I'm
modeling), I can just use "@operator" instead.

That said, if you have a class named "SystemClass" because you don't want to
name it "System", then the question becomes: why the hell would you have a
class named "System"? That's the worst name for a class I can think of. It's
about as descriptive and evocative as a brown paper bag. At the very least
it should be some *kind* of system, but even then...

Do you have ObjectClass, by any chance?

 

[Peter Duniho]

I'm an old Hungarian (e.g. "clsSystem") fan that came reluctantly to the
other side.

I was told how it was no longer needed since one could just mouse over a
term to see the type.

I've heard a number of Intellisense-based arguments in favor of abandoning
Hungarian. Suffice to say, they don't sway me. If anything, the fact
that Intellisense is strictly alphabetical just makes me like Hungarian
the more.

However, for various reasons, everywhere in our new project the type is
appended to the object name (e.g. "SystemClass").

Well, I'd agree that's silly.

I definitely think something is needed because so many of our words are
reserved keywords anyway, but doesn't this make the argument against
Hungarian moot?

I disagree with several of the points that Jeroen made in his reply,
including the implication that it's okay to have variable named the same
as some reserved word in the language. There a some good reasons for the
"@" symbol to be used in a variable name, but IMHO none of those reasons
have anything to do with hand-coded, run-of-the-mill code.

Reserved words should be avoided as variable names at all costs, IMHO.

I do understand that Hungarian requires all developers to know the
3-char prefix for every type, but the trade-off is all that wordiness
when the type is put as a suffix.

IMHO, Hungarian does not dictate three-character prefixes and/or type
tags. I've used four, even five characters sometimes. Just because it's
Hungarian, that doesn't mean it has to be hard to figure out. In fact,
the whole point of Hungarian is to make the code more transparent. There
are a number of very common one- and two-letter identifies in Hungarian
that are fine, because they are so common and easy to remember. But you
shouldn't feel that you have to force your code into that mold, if there
are longer tags that make more sense.

I'm not going to get into a whole Hungarian good/bad debate here, having
"been there, done that" (Google Groups will show you the thread in this
newsgroup, some time ago). And frankly, it sounds to me like your
question is more about whether to include the full type name as part of
the variable name. Personally, I think for that specific question the
answer is that it's just as silly as you seem to think it is.

And for what it's worth, I may be the last person left using Hungarian, at
least in the context of C#. But I like it, and I will continue to do so
(I do it in Java too...it hasn't come up yet, but I suspect that would
_really_ drive the hard-core Java crowd up the wall).

Pete

 

[Ronald S. Cook]

Thanks for the info. I was thinking of "System" as a good example because
in the cable industry a "system" is a cable system. I know what you'll
say... "CableSystem" but that's more typing

Thanks

 

[Jeroen Mostert]

I disagree with several of the points that Jeroen made in his reply,
including the implication that it's okay to have variable named the same
as some reserved word in the language.

If the choice is between using "@operator" to name my operators, and not
calling them "operator" because C# already has a keyword "operator" that's
used for operator overloading... I'll pick what's behind door number one.

There a some good reasons for the "@" symbol to be used in a variable
name, but IMHO none of those reasons have anything to do with hand-coded,
run-of-the-mill code.

The only *other* reason is when you have no choice: an object or method
defined in another CLR language is carrying a name that, by some stroke of
bad luck, is the same as a keyword in your language. And I'll immediately
grant you that that's its primary and intended use.

Reserved words should be avoided as variable names at all costs, IMHO.

Contrived names should avoided as variable names even more, IMNSHO.

This is where we'll just agree to disagree, I suppose. Look, I'm not
advocating for a return to the days of Fortran, where you could write down
such delicacies as

IF IF = THEN THEN THEN = IF

And I'm not about to name every other variable "@class" or "@string". But I
*will* trust the readers and maintainers of my code to not only not be
confused if I use a local variable named "@operator", but actually
appreciate that I didn't have to invent some meaningless suffix so as to not
confuse the compiler.

Good names matter. Every once in a (rare) while, your good name is a
keyword. If the language has a simple and elegant way of working around
that, don't mind if I use it.

As a user of Hungarian, you're just spoiled by the fact that your names are
*never* readable to outsiders. You have that luxury.

 

[Peter Duniho]

If the choice is between using "@operator" to name my operators, and not
calling them "operator" because C# already has a keyword "operator"
that's used for operator overloading... I'll pick what's behind door
number one.

That was clear from your previous post. I obviously disagree, though I
don't mind that.

The only *other* reason is when you have no choice: an object or method
defined in another CLR language is carrying a name that, by some stroke
of bad luck, is the same as a keyword in your language.

That's not the only other reason. Another place it comes up is in
computer-generated code where the identifiers are derived from some other
data. Allowing the generated code a way to explicitly state "this is a
variable" allows the generating code to be simpler, since it doesn't have
to worry about checking for reserved words and having some fallback
position.

And I'll immediately grant you that that's its primary and intended use.

I don't know what the primary and intended use it. What I do know is that
I disagree that a person writing code by hand should be using the "@"
symbol as a normal part of their programming techniques.

Contrived names should avoided as variable names even more, IMNSHO.

You and I obviously disagree with respect to what counts as "contrived".
I don't find Hungarian contrived at all. To the contrary, it has a very
well-ordered, predictable, and rational basis.

Pete

 

[Jeroen Mostert]

You and I obviously disagree with respect to what counts as
"contrived". I don't find Hungarian contrived at all. To the contrary,
it has a very well-ordered, predictable, and rational basis.

But I wasn't talking about Hungarian at all (I'm not stupid enough to open
that can of worms). Methinks thou doth protest too much.

I was talking about giving your variable an obvious name versus having to
invent a not-so-obvious because it clashes with a keyword -- obviously, if
you use Hungarian, it's just about inconceivable that you ever have that
problem.

 

[Michael C]

I've heard a number of Intellisense-based arguments in favor of abandoning
Hungarian. Suffice to say, they don't sway me. If anything, the fact
that Intellisense is strictly alphabetical just makes me like Hungarian
the more.

Except then you need to know the type of something to use it. Is count going
to be intCount or lngCount? The real issue with hungarian notation is that
it's impossible to keep it consistant. You might, if you really struggle,
get all your developers inhouse using the same standard but when you get
external code it will most certainly be different.

Reserved words should be avoided as variable names at all costs, IMHO.

Once I would have agreed with you but after using it I don't see what the
issue is. Certainly you haven't given any reason why you think it's bad.

Michael

 

[Michael C]

Thanks for the info. I was thinking of "System" as a good example because
in the cable industry a "system" is a cable system. I know what you'll
say... "CableSystem" but that's more typing

CableSystem would be wrong imo because presumably it would be in the Cable
namespace. If all children objects prepend their parent's name we'd end up
with very long object names. I see this in databases all the time with
fields like CustomerFirstName, CustomerLastName etc.

Michael

 

[Peter Duniho]

But I wasn't talking about Hungarian at all (I'm not stupid enough to
open that can of worms). Methinks thou doth protest too much.

Fair enough.

I was talking about giving your variable an obvious name versus having
to invent a not-so-obvious because it clashes with a keyword --
obviously, if you use Hungarian, it's just about inconceivable that you
ever have that problem.

True, that.

But even without Hungarian, I think it's possible to have a variable name
that doesn't collide with a reserved word without the word being
contrived. Human languages are usually very flexible. For sure, I've
never run into a situation where exactly one English word was the only
possible way to describe a particular variable.

I don't think one should need to use a thesaurus to write software, but if
you're having trouble coming up with non-colliding variable names, maybe
that's an option.

Pete

 

[Peter Duniho]

Except then you need to know the type of something to use it. Is count
going
to be intCount or lngCount?

That's a red herring, as it's a question that only makes sense when you
are misusing Hungarian.

If you care, you may want to (re?)read the thread we already had awhile
back on this. But the basic issue that many of the people I've run into
who object to Hungarian have never actually used real Hungarian. Often
their only exposure is via the incredibly wrong deviation from Hungarian
that is exhibited in Microsoft's Win32 API.

The real issue with hungarian notation is that
it's impossible to keep it consistant.

That's not true. If you are using real Hungarian, there is never a
problem keeping your tags consistent. Consistency is a fundamental basis
of Hungarian.

[...]

Reserved words should be avoided as variable names at all costs, IMHO.

Once I would have agreed with you but after using it I don't see what the
issue is. Certainly you haven't given any reason why you think it's bad.

My personal opinion is that even with the "@" syntax, reserved words are
difficult to read. Even though the compiler has no trouble, my brain
cannot help interpreting them as if they are not reserved words.

YMMV.

Pete

 

[Jeroen Mostert]

But even without Hungarian, I think it's possible to have a variable
name that doesn't collide with a reserved word without the word being
contrived. Human languages are usually very flexible. For sure, I've
never run into a situation where exactly one English word was the only
possible way to describe a particular variable.

Of course not. That's not my point either. The point is that if there is one
blindingly obvious name, I want to use that. I don't want to spend thought
(however insignificant) on whether perhaps I should append -instance or -ref
or prefix a- or my- or leave out a few vowels (general approaches) or find a
closely related word or add in some part redundant from the context
(specific approaches). C# has given me a way to avoid that and they'll pry
it from my cold, dead hands!

"What's a good name for this variable" is worth spending time on. "What's
the second most obvious name for this variable" is not.

So far, the only variable name I've ever used this way actually has been
"@operator". Everything *else* in the system (the things that *aren't* C#)
calls it that. It helps that I practically never use operator overloading,
but even people who do would have a hard time getting confused, since the
contexts are wildly different (operator overloads have a very specific
syntax). Really, the only one who can get confused is the compiler.

It's not like I'm deliberately looking for ways to let keywords double as
variable names. I'm not going to use "bool @continue" or "double investment,
@return; return @return" any time soon. I do recognize the potential for
confusion, here.

I don't think one should need to use a thesaurus to write software, but
if you're having trouble coming up with non-colliding variable names,
maybe that's an option.

If you think using a thesaurus to come up with synonyms is a good solution,
it's obvious why we'll never agree on these things...

 

[Michael C]

That's a red herring, as it's a question that only makes sense when you
are misusing Hungarian.

I don't see how. If you don't know the type of something then you will have
trouble looking it up. This is probably ok if it's your own project but that
just because you remember the type of most variables.

If you care, you may want to (re?)read the thread we already had awhile
back on this. But the basic issue that many of the people I've run into
who object to Hungarian have never actually used real Hungarian. Often
their only exposure is via the incredibly wrong deviation from Hungarian
that is exhibited in Microsoft's Win32 API.

I'm not sure how to respond here. Are you trying to imply I have no
experience with Hungarian.

That's not true. If you are using real Hungarian, there is never a
problem keeping your tags consistent. Consistency is a fundamental basis
of Hungarian.

Clearly you've never worked in a team if you think there is no problem
Your statement "If you are using real Hungarian" says it all really because
in my experience everyone has their own version. Do you have some document
that specifies all the hungarian notation? Does this docuement list
everything that a developer might prefix? What about instances of their own
classes?

My personal opinion is that even with the "@" syntax, reserved words are
difficult to read. Even though the compiler has no trouble, my brain
cannot help interpreting them as if they are not reserved words.

That's a fair point.

Michael

 

[Lew]

CableSystem would be wrong imo because presumably it would be in the Cable
namespace. If all children objects prepend their parent's name we'd end up
with very long object names. I see this in databases all the time with
fields like CustomerFirstName, CustomerLastName etc.

I have to wonder why typing five extra characters is considered any kind of
problem. It is not any kind of argument against meaningful names that I can
imagine.

Long names aren't bad either.

Consider that a successful program will spend MUCH more of its life being
maintained than developed. Self-documenting names are much more important to
maintainers than saving a few nano-ergs of typing energy can be to the
developer, especially with IDEs that provide all sorts of shortcuts to
inserting long names.

Names need to be meaningful in the problem domain and to make maintenance
easier. Do not use negligent laziness as an engineering principle.

 

[Peter Duniho]

I don't see how.

Because it's a misconception that the literal type of a variable is what's
used for the tag. Your question presents a misuse of Hungarian, and thus
isn't a useful question in the context of discussing correct Hungarian.
It distracts from questions that _are_ useful, and thus is a red herring.

If you don't know the type of something then you will have
trouble looking it up. This is probably ok if it's your own project but
that
just because you remember the type of most variables.

If you know _how_ the variable is used, _what_ it represents, then you
know the tag. If you don't know those things, you need to learn them
before working on the code. And that's true with or without Hungarian.

I'm not sure how to respond here. Are you trying to imply I have no
experience with Hungarian.

You don't seem to have experience with correct Hungarian. Whether you do
or not I can't say.

All I can comment on in the context of replying to your previous post is
that in code where correct Hungarian is used, you'd never see a variable
named "intCount" or "lngCount". The name "Count" indicates to me that the
variable is a count of something, which means that the correct Hungarian
tag would be "cXXX" where "XXX" is the type tag for whatever it is you're
counting (and may or may not actually be three characters).

Clearly you've never worked in a team if you think there is no problem

That's a really dumb statement, if for no other reason than that it's
easily proven false. Not only have I worked on a wide variety of teams,
the first team I worked with professionally is the one in which I learned
Hungarian. It worked very well, and did not cause any problem with
inconsistent tags.

Your statement "If you are using real Hungarian" says it all really
because
in my experience everyone has their own version. Do you have some
document
that specifies all the hungarian notation?

Well, the definitive document would be Charles Simonyi's original thesis.
I don't have a link to that handy, but Doug Klunder's write-up of the
convention is IMHO more accessible anyway, and does a reasonably good job
of describing the basic foundation of Hungarian.

There are a number of copies floating around. Here is one:
http://www.byteshift.de/msg/hungarian-notation-doug-klunder

As Doug Klunder was a part of one of the original production development
teams where Hungarian was actually used in practice (Multiplan at
Microsoft, if I recall correctly), I would consider his description of
Hungarian almost practically as definitive as the original thesis.

You may find it helpful to review the Wikipedia entry on Hungarian:
http://en.wikipedia.org/wiki/Hungarian_notation

In particular, where I talk about "correct Hungarian", this most closely
correlates to "Apps Hungarian", and the incorrect Hungarian used in the
Win32 API would be "Systems Hungarian". Note also that of the opinions
listed in the Wikipedia article arguing against Hungarian, they are
specifically regarding the "Systems" manifestation, and since that's not
correct Hungarian, they aren't useful in discussing whether Hungarian
itself is useful, flawed, etc.

Does this docuement list
everything that a developer might prefix? What about instances of their
own
classes?

Hungarian describes quite well how to create tags for your own data types
and usages. But that's irrelevant...the examples you provided are using
tags that appear to be assigned to built-in types, which is almost never
correct in Hungarian (exceptions being where the data in question is used
only as the built-in type itself...a common example of that exception
would be the use of "b" as the type tag for a byte, as in "rgb", an array
of bytes where all you care about is that it's bytes).

Pete

 

[Peter Duniho]

[...]
I have to wonder why typing five extra characters is considered any kind
of problem. It is not any kind of argument against meaningful names
that I can imagine.

Long names aren't bad either.

Let me emphasize that I agree completely with this.

Some people seem to be under the impression that Hungarian is about
shortening variable names. It's not. It's about (among other things)
providing useful semantic information in identifiers that isn't
necessarily represented solely in the type of a variable.

Some times a variable name can be shortened to just the prefix and type
tag, or just the type tag alone for that matter, but in most cases you'll
have some descriptive text after all of that, and that text does need to
be descriptive.

Not that Lew's statement had anything to do with Hungarian, but since it
came up in the thread, I wanted to clarify that.

Pete

 

[Peter Duniho]

[...]

I don't think one should need to use a thesaurus to write software, but
if you're having trouble coming up with non-colliding variable names,
maybe that's an option.

If you think using a thesaurus to come up with synonyms is a good
solution, it's obvious why we'll never agree on these things...

A good solution for what? A thesaurus is a _great_ solution for coming up
with synonyms. It's one of the best solutions there is.

But if you're talking about "a good solution for naming variables", there
should be absolutely nothing in anything I wrote that should cause you to
believe that I think using a thesaurus is a good solution for that.

I doubt we'd ever agree on the question at hand anyway. I don't think
there's any reason to put silly words in my mouth just to justify your own
disagreement.

Can't you just agree to disagree without mischaracterizing my own stance?

Pete

 

[Michael C]

I have to wonder why typing five extra characters is considered any kind
of problem. It is not any kind of argument against meaningful names that
I can imagine.

Long names aren't bad either.

Consider that a successful program will spend MUCH more of its life being
maintained than developed. Self-documenting names are much more important
to maintainers than saving a few nano-ergs of typing energy can be to the
developer, especially with IDEs that provide all sorts of shortcuts to
inserting long names.

Names need to be meaningful in the problem domain and to make maintenance
easier. Do not use negligent laziness as an engineering principle.

This is not about saving a few characters. There is simply no advantage to
having Customers.CustomerFirstName as opposed to Customers.FirstName.
Customers could be a child of something else so should we have
CompanyDatabase.CompanyDatabaseCustomers.CompanyDatabaseCustomerFirstName?

 

[Jeroen Mostert]

[...]

I don't think one should need to use a thesaurus to write software,
but if you're having trouble coming up with non-colliding variable
names, maybe that's an option.

If you think using a thesaurus to come up with synonyms is a good
solution, it's obvious why we'll never agree on these things...

A good solution for what? A thesaurus is a _great_ solution for coming
up with synonyms. It's one of the best solutions there is.

Yes, *obviously*. I know what a thesaurus is. Give me some credit, here. I
didn't know you were going to take me *literally*.

But if you're talking about "a good solution for naming variables",
there should be absolutely nothing in anything I wrote that should cause
you to believe that I think using a thesaurus is a good solution for that.

I don't.

I doubt we'd ever agree on the question at hand anyway. I don't think
there's any reason to put silly words in my mouth just to justify your
own disagreement.

I'm not. I'm setting up an obvious straw man to respond to your obviously
unhelpful suggestion. It's not meant to be taken literally.

Can't you just agree to disagree without mischaracterizing my own stance?

I think you and I should be communicating face-to-face, not in Usenet posts.
It's obvious we're not quite compatible in that medium yet.