Hungarian Notation Vs Pascal Notation?

[Grey Squirrel]

On wednesday my company will have an open ended discussion whether to
standardize hungarian notation or pascal/cammel case notation. We'd
love to recieve some feedback on what other people are using out
there
and why. Thanks!

 

[Guest]

Well, it's been a while since Hungarian Notation was used industry wide (or
close anyway...) and it seems that the combination of Camel Casing (private
variables, local variables) and Pascal Casing (methods and public variables)
properties is the way forward. I use this as part of my own coding
conventions. MS actively discourages the use of Hungarian Notation.

 

[Nick]

On wednesday my company will have an open ended discussion whether to
standardize hungarian notation or pascal/cammel case notation. We'd
love to recieve some feedback on what other people are using out there
and why. Thanks!

We use pascal and cammel case. Not only because it is the standard
coding convention for .NET as seen in

* http://msdn2.microsoft.com/en-us/library/ms229043.aspx
* http://msdn2.microsoft.com/en-us/library/ms229045.aspx

--- from coding standards on MSDN ---
Do not use abbreviations or contractions as parts of identifier names.
For example, use OnButtonClick rather than OnBtnClick.
------

In addition we stay way from Hungarian notation because I encourage my
developers to take a more object oriented approach to their naming by
naming things by functional group names. Such as

LoginName
LoginPassword
LoginGoToLocationList
LoginSendButton

Instead of the Hungarian way which scatters the names all over the
list like:

txtName
txtPassword
ddlLocation
btnSend

In addition another benefit of not using Hungarian is the ability to
be more flexible and agile when coding.

If you decide all Lists are going to end with the postfix "List" for
drop down, combo boxes, and everything in between. It is a lot easier
to adjust the interface if somebody wants to go from a combo box to a
drop down list.

SomethingList

However if you use Hungarian you have to rename all your variables to
go from a drop down list to a combo box, if you still want to maintain
your naming convention, which is the original reason why you are
having this meeting.

ddlSomething
cmbSomething

Hope this helps.

 

[Shawn B.]

On wednesday my company will have an open ended discussion whether to

standardize hungarian notation or pascal/cammel case notation. We'd
love to recieve some feedback on what other people are using out
there and why

Hungarian is dead in the .NET world. I mostly fallow what is easiest to
read and maintain, and by far, it ends up nearly following the same
convention as the .NET framework itself. In fact, Microsoft has published a
set of guidelines for developing .NET components that are identicle to the
same standards that they employ on the framework itself.

I've found, no one wants to follow any standard but their own. Even at my
company, people have finally come around to standardizing, but it make the
code easier to read and much easier to predict and makes the code blend in
"naturally" with the rest of the .NET framework anyone else's code that
follows the guidelines (E.G. most 3rd party toolkits).

Granted, the Win32/Win64 API follows the hungarian standard, there was a
reason for that.

I find it much easier to PascalCase/camelCase notation:

public void VerifyPassword(string userName, string password);

than it is to read the hngArian

public void VerifyPassword(string strUser, string strPassword);

In all reality, .NET languages, being strongly typed, eliminate the nead for
hungarian notation in part also because intellisense is so good.


Thanks,
Shawn

 

[Peter Duniho]

[...]
In all reality, .NET languages, being strongly typed, eliminate the nead
for hungarian notation in part also because intellisense is so good.

IMHO, this reflects an incomplete understanding of why Hungarian is useful.

Even in .NET, one can have variables of the same language type but which
are not actually of the same semantic type.

I readily admit that Hungarian interferes with the ordering of items in
Intellisense, but the fact is that because that ordering is always
alphabetic with no option to the developer to group things more logically,
even without using Hungarian you still get lots of things in a
semantically random order. I don't see that Hungarian makes this any
worse. The context of .NET certainly has not obviated many benefits of
Hungarian, never mind eliminated the need for it.

That said, there's already been a grand discussion on the pros and cons of
various coding conventions within these newsgroups. The original poster
may find it valuable to read through that before asking for the issue to
be rehashed here all over again. Look here:
http://groups.google.com/group/micr...read/thread/cadbc77928d7be28/5b50312c2cdda10c

Pete

 

[Matt Lacey]

On wednesday my company will have an open ended discussion whether to
standardize hungarian notation or pascal/cammel case notation. We'd
love to recieve some feedback on what other people are using out
there
and why. Thanks!

Note that there are tow types of hungarian notation
1. Apps Hungarian (theoretically good, misunderstood and not
appropriate to all situations)
2. Systems Hungarian (What most people know as 'Hungarian'. The only
thing it has going for it is that it is better than no standard at
all)
See http://www.joelonsoftware.com/articles/Wrong.html for more on
this.

If you are doing .NET development, use the standards set out by
Microsoft (see links in Nick's reply) but also use FxCop (http://
www.gotdotnet.com/Team/FxCop/) to ensure that the conventions are
followed.

 

[Cowboy \(Gregory A. Beamer\)]

Pascal/Camel

Why?

* More readable
* Easier to understand
* Do not have to refactor type names if you find you need a larger field
size (integers)

To me, the major benefit of Hungarian was the ability to see what type a
variable was anywhere in the code. If you can hover and find out (as you can
now), there is little benefit to these types of names.

--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

*********************************************
Think outside the box!
*********************************************

 

[Peter Duniho]

Pascal/Camel

Why?

* More readable

Debatable. As with any language, once you are accustomed to reading
Hungarian code, it's as easy as plain English.

* Easier to understand

Very debatable. Especially if one assumes that "to understand" is
supposed to be different somehow than simply "readable" as in your
previous point. Hungarian allows a significant amount of information to
be encapsulated within the identifier, which can make things much easier
to understand than otherwise.

* Do not have to refactor type names if you find you need a larger field
size (integers)

See my other post. If you think that changing the underlying type of a
variable requires changing the name of the variable, you aren't using
Hungarian correctly.

This is a common misunderstanding, not helped at all by the fact that
Microsoft's own Win32 API uses a broken dialect of Hungarian that doesn't
meet the original intent of Simonyi's work at all.

To me, the major benefit of Hungarian was the ability to see what type a
variable was anywhere in the code. If you can hover and find out (as you
can now), there is little benefit to these types of names.

You can learn the built-in type of the variable. That doesn't necessarily
tell you what the semantic type of the variable is.

For example, if you hover over a variable and it tells you that the
variable is an "int", can you tell me from that alone whether that "int"
is representing a pixel offset? A pixel count? An index into an array?
A count of items within an array? If it's an index into, or count of
items within, an array, what kind of array does it index? A variable
named using proper Hungarian tells you all of this and more.

You see...Hungarian is so much more than just taking the declared type of
a variable and using that to attach a prefix to a variable name. I admit,
this is a very common preconception, but all of the detractors I've seen
of Hungarian have completely failed to appreciate this point. They are
making critical comments of something without even understanding it.

Now, that said...in the context of .NET I agree that the .NET coding
conventions (which do not include Hungarian) should be followed any time
one is coding for public consumption. But I wish people would stop making
incorrect statements about supposed failings of Hungarian.

Pete

 

[Jon Skeet [C# MVP]]

You see...Hungarian is so much more than just taking the declared type of
a variable and using that to attach a prefix to a variable name. I admit,
this is a very common preconception, but all of the detractors I've seen
of Hungarian have completely failed to appreciate this point. They are
making critical comments of something without even understanding it.

I understand that and I still find Hungarian a pain to read. Could I
get used to it? Yes, I dare say I could - but given two styles, unless
there's a clear benefit to using one style, I'd rather take the one
which *doesn't* require me to get used to it.

I believe that variables should explain their semantic meaning anyway,
without requiring prefixes. I don't need wgt and hgt to mean weight and
height - if I have a field which has something to do with someone's
weight, it will be called "weight" or something equally descriptive.

I *certainly* don't see any benefit in names like "strName" instead of
"name" when it's obvious (in the vast majority of situations) that a
name is going to be a string.

 

[Peter Duniho]

I understand that and I still find Hungarian a pain to read. Could I
get used to it? Yes, I dare say I could - but given two styles, unless
there's a clear benefit to using one style, I'd rather take the one
which *doesn't* require me to get used to it.

The primary benefit, the motivation behind Charles Simonyi's development
of Hungarian, is to be able to quickly verify that the code is correct as
written. Of course, that assumes the Hungarian was used correctly, so one
you might argue that it just moves where the possible error could be. But
IMHO once you know what you're doing in Hungarian, it's harder to choose
the wrong names than it is to write the wrong code.

I feel this is a clear benefit (there are others, but this is the main
one). For me, Hungarian clearly has an advantage over plain-English
naming, and it's not simply a matter of which one is easier to get used
to. That said, Hungarian isn't difficult anyway. Granted, I've been
using Hungarian nearly 20 years and so it's second-nature to me. But it
wasn't hard to learn in the first place. Way easier than learning a whole
new programming language. If you can code, you can learn Hungarian and do
so easily.

I believe that variables should explain their semantic meaning anyway,
without requiring prefixes.

The problem is that the English language is ambiguous. You can't write
variable names in English (or any other human language) and reliably have
them explain their semantic meaning. Or if they do, they may be a
half-dozen words long or more. Sometimes, a short word suffices, but
often a short word does not. What name do you pick then?

Intellisense does help with typing, so maybe you don't mind lengthy
names. But I do. I don't want variable names that are 20 or 30
characters long. Hungarian allows me to concisely, reliably, and
consistently name variables that are semantically unambiguous and readily
compared with the code surrounding them in a way that allows me to easily
see that the code is correct. Plain-English names simply don't allow for
this.

I don't need wgt and hgt to mean weight and
height - if I have a field which has something to do with someone's
weight, it will be called "weight" or something equally descriptive.

You are displaying your lack of understanding of Hungarian (and making my
point in the process). It's highly unlikely that you'd ever have a
variable named "wgt" and "hgt" to mean "weight" and "height". It's a
fallacy to think that Hungarian's sole purpose is to remove all vowels
from a variable name. And yes, when viewed with such a simplistically
incorrect perception of Hungarian, I can see why one might shy away from
it.

But that's my point. Yours IS a simplistically incorrect perception of
Hungarian. Once again, the argument against Hungarian is based on
incorrect information.

In your example, you'd much more likely have variables name "kgWeight" and
"cmHeight". One nice thing is that, as you can see, those variables are
self-documenting. You don't have to wonder what units the height and
weight are in...the variable name tells you. This isn't the main reason
for being of Hungarian, but it's a secondary benefit that shows up often.

I *certainly* don't see any benefit in names like "strName" instead of
"name" when it's obvious (in the vast majority of situations) that a
name is going to be a string.

Well, personally I think that in .NET using "strName" instead of "name" is
MUCH better. Ironic that you should pick that example, because a "name"
could in fact be anything. It doesn't have to be a "string" and bugs
happen because while something is true "in the vast majority of
situations", there can be exceptions and failing to notice the exception
is what causes the bug. In other languages, there's much less robust
conversion from various types to strings, but in .NET you might actually
not get a compiler error using something as a string when it's not one,
but still have an undesirable outcome.

Using Hungarian, it's clear reading any code that references that variable
that it's a string. Conversely, if it's a situation in which the variable
happens NOT to be a string, it's also obvious.

Like I said, I wish people would at least learn about Hungarian before
discounting it. I can appreciate a difference of opinion when the
opinions involved are informed, and I readily admit that there are
subjective reasons one might prefer other coding standards over
Hungarian. But it really bugs me when people create their opinions
without facts to support those opinions.

Pete

 

[Jon Skeet [C# MVP]]

In your example, you'd much more likely have variables name "kgWeight" and
"cmHeight". One nice thing is that, as you can see, those variables are
self-documenting. You don't have to wonder what units the height and
weight are in...the variable name tells you. This isn't the main reason
for being of Hungarian, but it's a secondary benefit that shows up often.

That's a reasonable example - and these days, if I'm passing an integer
for a number of milliseconds, I *would* use something like "delayInMs"
rather than just "delay". However, I don't apply it to everything -
only where there's ambiguity.

Well, personally I think that in .NET using "strName" instead of "name" is
MUCH better. Ironic that you should pick that example, because a "name"
could in fact be anything. It doesn't have to be a "string" and bugs
happen because while something is true "in the vast majority of
situations", there can be exceptions and failing to notice the exception
is what causes the bug.

How many times has such a bug actually hit you, out of interest? I
can't remember the last time one did.

In other languages, there's much less robust
conversion from various types to strings, but in .NET you might actually
not get a compiler error using something as a string when it's not one,
but still have an undesirable outcome.

Using Hungarian, it's clear reading any code that references that variable
that it's a string. Conversely, if it's a situation in which the variable
happens NOT to be a string, it's also obvious.

Why not only make it clear when it's *not* the common case? If 99% of
the time it'll be a string, make the variable name longer when it's not
a string, but leave it as just "name" when it's a string.

Like I said, I wish people would at least learn about Hungarian before
discounting it. I can appreciate a difference of opinion when the
opinions involved are informed, and I readily admit that there are
subjective reasons one might prefer other coding standards over
Hungarian. But it really bugs me when people create their opinions
without facts to support those opinions.

Well, when you said that my height/weight example was demonstrating my
ignorance, I should point out that it's an example I've seen used
precisely to get away from the idea that it's only pointing out the
declared type. See http://www.thescripts.com/forum/thread451431.html as
an example. Just because you don't think it's a good example, please
don't discount me as not having the faintest clue what Hungarian
notation's about.

Units is admittedly a much better example - but as I said, it's easy to
use that *where relevant* without making the whole code less readable.
(Likewise I believe that "delayInMs" is easier to read than "msDelay" -
possibly just a personal thing though.)

Disambiguate where appropriate, where the risk of problems outweighs
the readability cost. Don't bother disambiguating where it's very
unlikely that the more readable version will cause problems. If you
find you *do* run into bugs that way, balance accordingly - as I say, I
can't remember the last time that happened, with the exception of units
of time, where I've changed my convention accordingly.

 

[Peter Duniho]

That's a reasonable example - and these days, if I'm passing an integer
for a number of milliseconds, I *would* use something like "delayInMs"
rather than just "delay". However, I don't apply it to everything -
only where there's ambiguity.

There is always ambiguity. Unless you have clearly documented, somewhere
that every person who ever looks at your code will see, the default type
of unambiguated (I love making up new words ) variables names then lack
of specification within the name is ambiguity.

[...] It doesn't have to be a "string" and bugs
happen because while something is true "in the vast majority of
situations", there can be exceptions and failing to notice the exception
is what causes the bug.

How many times has such a bug actually hit you, out of interest? I
can't remember the last time one did.

My code has very few bugs in it, and mis-matching strings and other types
just never happens. But I use Hungarian nearly all the time, and I
attribute much of the inherent correctness of the code I write to the
consistent use of Hungarian.

I've seen type mis-matches in other people's code, but it just doesn't
happen to me. But the lack of it happening to me is a reinforcement of my
use of Hungarian, not a reason to abandon it.

Semantic type mis-matches happen all the time. A very famous one resulted
in the loss of a Mars spacecraft. Every piece of software I've ever used
has bugs in it, and I would be willing to bet that at least one of the
bugs in each of those programs involves a mis-match of semantic type.

Why not only make it clear when it's *not* the common case? If 99% of
the time it'll be a string, make the variable name longer when it's not
a string, but leave it as just "name" when it's a string.

That's a fine rule if you can follow it 100%. The point is that people
don't follow such rules 100%. The problem comes up with they are supposed
to use a longer, more-specific name but don't. The very fact that there
is an exceptional case (that is, "always qualify the variable name, except
when it's a string") allows for a programmer to write code without a
proper qualification but which still looks correct even though it's not.

By allowing exceptions, you allow bugs.

Well, when you said that my height/weight example was demonstrating my
ignorance, I should point out that it's an example I've seen used
precisely to get away from the idea that it's only pointing out the
declared type. See http://www.thescripts.com/forum/thread451431.html as
an example.

The only mention I saw in that thread of height/weight was your own. And
sure, it suggests you understand more about Hungarian than you've
exhibited here. I wasn't aware that I was obligated to have read that
thread before replying to your posts in this thread.

I also saw some familiar names in that thread, writing familiar, incorrect
claims about Hungarian.

Just because you don't think it's a good example, please
don't discount me as not having the faintest clue what Hungarian
notation's about.

Well, you are the one who suggested that Hungarian would result in
variables names like "hgt" and "wgt". That sure reads like someone who
doesn't have the faintest clue about what Hungarian notation is about. If
you have a clue, and want that to be understood, I recommend you don't
come up with bogus examples that makes false implications about Hungarian.

Like I said, I agree that there are valid subjective reasons to choose
another convention over Hungarian. But you haven't presented them, nor
has someone else, and what *has* been presented (by you and others) has
uniformly misstated what Hungarian is, what it's useful for, and how it's
used. If one is going to reject Hungarian, they ought to at least do so
based on valid reasons.

[...]
Disambiguate where appropriate, where the risk of problems outweighs
the readability cost. Don't bother disambiguating where it's very
unlikely that the more readable version will cause problems.

And as I pointed out at the beginning of this post, things are always
ambiguous, absent clear qualification. If you allow for unqualified
variable names where one must assume they carry a certain meaning, then
you allow for bugs where those unqualified variable names don't actually
carry the meaning that they "normally" do.

Pete

 

[Jon Skeet [C# MVP]]

There is always ambiguity. Unless you have clearly documented, somewhere
that every person who ever looks at your code will see, the default type
of unambiguated (I love making up new words ) variables names then lack
of specification within the name is ambiguity.

I think there are plenty of times when it's unambiguous what things
mean. If I've got an int variable "activeThreads" then that's clearly
the number of active threads (in whatever context) without me having to
elaborate in the variable name.

[...] It doesn't have to be a "string" and bugs
happen because while something is true "in the vast majority of
situations", there can be exceptions and failing to notice the exception
is what causes the bug.

How many times has such a bug actually hit you, out of interest? I
can't remember the last time one did.

My code has very few bugs in it, and mis-matching strings and other types
just never happens. But I use Hungarian nearly all the time, and I
attribute much of the inherent correctness of the code I write to the
consistent use of Hungarian.

If you attribute that correctness to Hungarian, to what do you
attribute the fact that I *haven't* mismatched strings and other types
often, while not using Hungarian?

I've seen type mis-matches in other people's code, but it just doesn't
happen to me. But the lack of it happening to me is a reinforcement of my
use of Hungarian, not a reason to abandon it.

Semantic type mis-matches happen all the time. A very famous one resulted
in the loss of a Mars spacecraft. Every piece of software I've ever used
has bugs in it, and I would be willing to bet that at least one of the
bugs in each of those programs involves a mis-match of semantic type.

I think that's a bold claim - of course, we'll never know. On the other
hand, you're more than welcome to look at my MiscUtil library, find
bugs (of which I'm sure there are plenty) and spot which ones would
have been solved by using Hungarian notation.

http://pobox.com/~skeet/csharp/miscutil

The project I'm on at work is now nearing completion, and we've been
concentrating on fixing bugs. Guess how many have been due to type
mismatches...

That's a fine rule if you can follow it 100%. The point is that people
don't follow such rules 100%. The problem comes up with they are supposed
to use a longer, more-specific name but don't. The very fact that there
is an exceptional case (that is, "always qualify the variable name, except
when it's a string") allows for a programmer to write code without a
proper qualification but which still looks correct even though it's not.

By allowing exceptions, you allow bugs.

By not allowing exceptions, you end up with less readable code (IMO,
and clearly in the opinion of others) which allows other kinds of bugs.

Can you give me any reason to change my habits given that I can't
remember running into a bug along the lines you describe other than in
situations where I've already changed my habits now?

The only mention I saw in that thread of height/weight was your own. And
sure, it suggests you understand more about Hungarian than you've
exhibited here. I wasn't aware that I was obligated to have read that
thread before replying to your posts in this thread.

LOL - I didn't actually even notice it was my own post. Deep apologies
on that front. And no, I didn't expect you to have read that thread - I
just don't expect to be patronised.

I also saw some familiar names in that thread, writing familiar, incorrect
claims about Hungarian.


Well, you are the one who suggested that Hungarian would result in
variables names like "hgt" and "wgt". That sure reads like someone who
doesn't have the faintest clue about what Hungarian notation is about. If
you have a clue, and want that to be understood, I recommend you don't
come up with bogus examples that makes false implications about Hungarian.

Claiming I haven't the "fainted clue" about what Hungarian notation is
about is completely incorrect, as well as extremely patronising. I
certainly understand the common misconception that it is to make it
obvious what the *declared* type of a variable is. That's where the
height/weight example comes from - two variables, eg hgtPerson and
wgtPerson, could both have the same declared type, but clearly be
semantically incomparable. I understand that Hungarian makes that
obvious - but I believe more readable variable names also make it
obvious.

Nothing you've said about Hungarian in this thread has been new to me
(unless you count the units example as being a good example that I'll
use in the future - the concept wasn't new, just the fact that it's a
good example). If I was so supremely ignorant about Hungarian,
shouldn't you have been able to educate me by now?

Like I said, I agree that there are valid subjective reasons to choose
another convention over Hungarian. But you haven't presented them, nor
has someone else, and what *has* been presented (by you and others) has
uniformly misstated what Hungarian is, what it's useful for, and how it's
used. If one is going to reject Hungarian, they ought to at least do so
based on valid reasons.

My reasons are:
1) The perceived disadvantages of *not* using Hungarian haven't hit me
2) I strongly believe that Hungarian *is* less readable without
training oneself to do it.

Suppose I suggested writing all variable names backwards. I dare say
people could train themselves to read backwards at speed, but until
presented with a good reason to do so, it would be foolish to think it
a good idea.

Rather than me presenting you with reasons to reject Hungarian, isn't
the onus on you to present reasons which make sense to me (i.e. fixing
the type of bug which I *have* experienced) to move from a system which
is more easily readable to a less readable one?

[...]
Disambiguate where appropriate, where the risk of problems outweighs
the readability cost. Don't bother disambiguating where it's very
unlikely that the more readable version will cause problems.

And as I pointed out at the beginning of this post, things are always
ambiguous, absent clear qualification. If you allow for unqualified
variable names where one must assume they carry a certain meaning, then
you allow for bugs where those unqualified variable names don't actually
carry the meaning that they "normally" do.

The proof should be in the pudding. If this were a serious issue (which
I believe simple readability to be) then I should be seeing significant
numbers of bugs due to type mismatches. I can't remember *any* beyond
units, which I've already conceded. Do you put that down to luck, a bad
memory, or miraculously being a brilliant engineer? (For the record,
I'm certainly not claiming the latter.)

 

[Peter Duniho]

I think there are plenty of times when it's unambiguous what things
mean. If I've got an int variable "activeThreads" then that's clearly
the number of active threads (in whatever context) without me having to
elaborate in the variable name.

It's not clear to me. What kind of thread is that that you are counting?
When you include the word "Threads" in your variable name, does that mean
a .NET Thread class instance? Does it mean a worker thread from the
thread pool? Does it mean a native Win32 thread? Is it a thread handle,
or a thread ID? Or a .NET reference?

It's ambiguous. Using Hungarian, you would have a specific type tag
assigned to a specific data structure name, with a unique association.
That's part of the rules of Hungarian. Without Hungarian, I have no idea
whether you are using the word "Thread" to uniquely describe a specific
reference to a thread, or if different variables all of which have the
name "Thread" in it could be referring to different kinds of data.

If you attribute that correctness to Hungarian, to what do you
attribute the fact that I *haven't* mismatched strings and other types
often, while not using Hungarian?

I make no attribution. How could I? I have no experience with your code,
or your development style. It would be foolish of me to assert anything
one way or the other about how YOU code.

[...] Every piece of software I've ever used
has bugs in it, and I would be willing to bet that at least one of the
bugs in each of those programs involves a mis-match of semantic type.

I think that's a bold claim

That's your prerogative. I obviously don't. To me, it's a matter of
statistics. There are so many bugs in each piece of software, the chances
that such a bug does not exist seems extremely low to me. Certainly worth
betting on.

- of course, we'll never know. On the other
hand, you're more than welcome to look at my MiscUtil library, find
bugs (of which I'm sure there are plenty) and spot which ones would
have been solved by using Hungarian notation.

http://pobox.com/~skeet/csharp/miscutil

Unless you're paying me, and well, that's a waste of my time.

The project I'm on at work is now nearing completion, and we've been
concentrating on fixing bugs. Guess how many have been due to type
mismatches...

I don't know. How many bugs have you documented throughout the entire
development cycle?

By not allowing exceptions, you end up with less readable code (IMO,
and clearly in the opinion of others) which allows other kinds of bugs..

Such as? What sorts of bugs do you assert Hungarian creates?

Can you give me any reason to change my habits given that I can't
remember running into a bug along the lines you describe other than in
situations where I've already changed my habits now?

Sure. Hungarian isn't just about preventing that sort of bug. But you
would have to actually read about Hungarian to learn that. Frankly, I
don't feel that my role here is to evangalize Hungarian. It's no big deal
to me if people choose not to use it. I'm not going to redocument
everything about Hungarian here, when people who are actually interested
could just use Google and learn about it for themselves.

That said, if you are really interested, you might read what's on these
web pages:

http://www.idleloop.com/hungarian/index.html
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnvs600/html/hunganotat.asp

You can even read Simonyi's original thesis here (it's a Postscript file,
so you'll need something that can display or print Postscript):
http://www.parc.xerox.com/about/history/publications/bw-ps/csl76-7.ps

Keeping in mind, of course, that many of the suggested type tags are
indeed outdated in the .NET context, but that doesn't invalidate the
usefulness of Hungarian. It simply means one needs to adapt to concept to
..NET with new, more appropriate tags. More importantly, much of the rest
of the notation can be used unchanged; prefixes and suffixes in particular
still apply just as well as they always have.

LOL - I didn't actually even notice it was my own post. Deep apologies
on that front. And no, I didn't expect you to have read that thread - I
just don't expect to be patronised.

I'm sorry if you feel patronized. I have only pointed out where you and
others have made incorrect statements about Hungarian. I can only make
assessments of your knowledge of Hungarian based on what you actually
write here, and for the most part what has been written here displays
ignorance of Hungarian.

I reiterate: if you are not ignorant of Hungarian, I recommend you refrain
from writing incorrect things about it. If anything, it is more of a
blemish on your reputation to claim knowledge and then write falsehoods,
than to simply not have the knowledge in the first place.

Claiming I haven't the "fainted clue" about what Hungarian notation is
about is completely incorrect, as well as extremely patronising.

I made no such claim. I simply pointed out that what's been written here
against Hungarian appears to be written by people without the faintest
clue. There's a difference, and it has to do with the line between whatI
can truly know about what you and others know (which is very little,
frankly) and what impression *you* give of what you know.

[...]
My reasons are:
1) The perceived disadvantages of *not* using Hungarian haven't hit me

This is the only valid reason of the two, and frankly that's something you
need to deal with on your own. I don't see it as my role to convince you
to use Hungarian.

2) I strongly believe that Hungarian *is* less readable without
training oneself to do it.

Practically everything about programming is "less readable" without
training oneself to do it. The requirement of training and practice in no
way argues against use.

Suppose I suggested writing all variable names backwards. I dare say
people could train themselves to read backwards at speed, but until
presented with a good reason to do so, it would be foolish to think it
a good idea.

Of course it would. It would be foolish to think anything a good idea if
it didn't provide some benefit. Duh.

Rather than me presenting you with reasons to reject Hungarian, isn't
the onus on you to present reasons which make sense to me (i.e. fixing
the type of bug which I *have* experienced) to move from a system which
is more easily readable to a less readable one?

No. I have no onus to convince you at all.

Let me see if I can make this plain, since you don't seem to get it yet:

My contribution here is not intended to sway people to the side of
Hungarian. I couldn't care less who uses Hungarian, and whether people
like it or not.

Rather, my point is simply that the only arguments presented here against
Hungarian have been based solely on an incorrect understanding of
Hungarian. Why bother to argue against something if you aren't going to
bother to get the facts right?

I would have the same objection if someone argued against using VB .NET by
claiming that the .NET Framework runs slower with code written in VB .NET,
or if someone argued against driving to France from England via the
"chunnel" by claiming that your tires would melt because you get too close
to the core of the Earth. It's not that I really care how someone decides
these patently subjective issues, it's just that I feel strongly that any
such decision should be based on correct information.

The proof should be in the pudding. If this were a serious issue (which
I believe simple readability to be) then I should be seeing significant
numbers of bugs due to type mismatches. I can't remember *any* beyond
units, which I've already conceded. Do you put that down to luck, a bad
memory, or miraculously being a brilliant engineer? (For the record,
I'm certainly not claiming the latter.)

I don't "put it down" to anything. That's not my place to do.

The fact remains that when using Hungarian, I code faster, more correctly,
and find that my code remains more consistent over time than using other
naming conventions. The proof IS in the pudding, for me. It's my opinion
that someone who rejects Hungarian ought to at least learn it and try it
for some period of time before deciding it's awful.

That said, I grant that the entire world is filled with people who
prejudge. Even just looking at the computer world, it is filled with
people who prejudge. They argue in favor of their favorite software,
their favorite hardware, their favorite coding standards, their favorite
data structures, their favorite file formats, mostly based on invalid
information.

Frankly, I probably wouldn't have even written anything here except for
the fact that the claims about Hungarian have been so obviously wrong that
it's fairly easy to pick holes in them. I quickly tire of what
essentially amount to religious arguments, and most of the time stay out
of them altogether. I guess I'm just frustrated to see the same old
anti-Hungarian falsehoods showing up here over and over again.

So mark me down as "can't help myself", but at least for now I think I've
written all that I feel motivated to write about Hungarian. Open-minded
people who have been reading this will take the initiative to actually
learn about Hungarian, to try it for some time, see how it helps them when
they've really learned it. Others won't. Either way, it's no skin off my
nose.

Pete

 

[Jon Skeet [C# MVP]]

It's not clear to me. What kind of thread is that that you are counting?
When you include the word "Threads" in your variable name, does that mean
a .NET Thread class instance? Does it mean a worker thread from the
thread pool? Does it mean a native Win32 thread? Is it a thread handle,
or a thread ID? Or a .NET reference?

It's ambiguous. Using Hungarian, you would have a specific type tag
assigned to a specific data structure name, with a unique association.
That's part of the rules of Hungarian. Without Hungarian, I have no idea
whether you are using the word "Thread" to uniquely describe a specific
reference to a thread, or if different variables all of which have the
name "Thread" in it could be referring to different kinds of data.

Well, that's where the "whatever context" comes in. Just how many
specific type tags do you have in total, if you'd have one for ".NET
Thread class instance" one for "worker thread from the thread pool"
etc? Sounds like a nightmare to me.

I make no attribution. How could I? I have no experience with your code,
or your development style. It would be foolish of me to assert anything
one way or the other about how YOU code.

But if there results of two naming conventions are the same, isn't it
foolish to attribute a lack of a certain type of bug in your code to
the difference in convention?

[...] Every piece of software I've ever used
has bugs in it, and I would be willing to bet that at least one of the
bugs in each of those programs involves a mis-match of semantic type.

I think that's a bold claim

That's your prerogative. I obviously don't. To me, it's a matter of
statistics. There are so many bugs in each piece of software, the chances
that such a bug does not exist seems extremely low to me. Certainly worth
betting on.

So do programs written using Hungarian notation have such bugs? If so,
the claim means nothing - it doesn't show anything about Hungarian
notation at all.

Unless you're paying me, and well, that's a waste of my time.

Well, it would demonstrate your point...

I don't know. How many bugs have you documented throughout the entire
development cycle?

Plenty (I won't give figures here just in case management are sensitive
- none of which have been due to this issue, that I'm aware of.

Such as? What sorts of bugs do you assert Hungarian creates?

It doesn't directly create bugs, but I believe that less easily
readable code is likely to have more bugs than more easily readable
code - as well as being harder to maintain, of course.

Sure. Hungarian isn't just about preventing that sort of bug. But you
would have to actually read about Hungarian to learn that. Frankly, I
don't feel that my role here is to evangalize Hungarian. It's no big deal
to me if people choose not to use it. I'm not going to redocument
everything about Hungarian here, when people who are actually interested
could just use Google and learn about it for themselves.

That said, if you are really interested, you might read what's on these
web pages:

http://www.idleloop.com/hungarian/index.html
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnvs
600/html/hunganotat.asp

I'll read them - I believe I've read the MSDN one before, in fact.

You can even read Simonyi's original thesis here (it's a Postscript file,
so you'll need something that can display or print Postscript):
http://www.parc.xerox.com/about/history/publications/bw-ps/csl76-7.ps

Keeping in mind, of course, that many of the suggested type tags are
indeed outdated in the .NET context, but that doesn't invalidate the
usefulness of Hungarian. It simply means one needs to adapt to concept to
.NET with new, more appropriate tags. More importantly, much of the rest
of the notation can be used unchanged; prefixes and suffixes in particular
still apply just as well as they always have.

I'm genuinely interested in the answer to my earlier question - just
how many tags do you use?

I'm sorry if you feel patronized. I have only pointed out where you and
others have made incorrect statements about Hungarian.

Could you state exactly which statement I've made is incorrect? I
completely agree that those who have stated that it's to show the
*declared* type are incorrect (with regard to Simonyi's original
intention)

I can only make assessments of your knowledge of Hungarian based on
what you actually write here, and for the most part what has been
written here displays ignorance of Hungarian.

I reiterate: if you are not ignorant of Hungarian, I recommend you refrain
from writing incorrect things about it. If anything, it is more of a
blemish on your reputation to claim knowledge and then write falsehoods,
than to simply not have the knowledge in the first place.

I reiterate - I don't believe I've written anything incorrect about
Hungarian. I've given a less-than-brilliant example, but that's about
it, I believe. (You misinterpreted my example, by the way, certainly
due to me not being very clear - I wasn't suggesting that "hgt" and
"wgt" would be the full variable names, but prefixes.)

If you can point out my mistake, I'm happy to learn - but I don't like
being belittled as being "completely ignorant" just for coming up with
a poor example.

I made no such claim. I simply pointed out that what's been written here
against Hungarian appears to be written by people without the faintest
clue. There's a difference, and it has to do with the line between what I
can truly know about what you and others know (which is very little,
frankly) and what impression *you* give of what you know.

That's a very fine line, and one which I don't believe stops the
implication from being insulting. "When did you stop beating your
wife?"

(You also haven't always been on the same side of the line. For
instance, the statement "Yours IS a simplistically incorrect perception
of Hungarian" is not a statement about the impression I give - it's a
definite statement about my perception, isn't it?)

[...]
My reasons are:
1) The perceived disadvantages of *not* using Hungarian haven't hit me

This is the only valid reason of the two, and frankly that's something you
need to deal with on your own. I don't see it as my role to convince you
to use Hungarian.

Funny, as that *appears* to be what you've been trying to do. I don't
believe I have anything to "deal with", as I don't believe I have a
problem.

Practically everything about programming is "less readable" without
training oneself to do it. The requirement of training and practice in no
way argues against use.

I disagree. While everything might require *some* training, I believe
the *level* of training is significant. I believe it takes less
training to become comfortable with "delayInMs" than "msDelay".

It's like the religious bracing argument - I believe that were a study
carried out of those with no previous experience, people would become
familiar and comfortable (to the extent of easily spotting problems
etc) with the "brace on a new line" style than with the K&R "brace at
the end of a line" style. That, for me, is an argument against the K&R
style.

Of course it would. It would be foolish to think anything a good idea if
it didn't provide some benefit. Duh.

Exactly - and given that I felt the pain of the problem it's meant to
solve, I see no benefit to Hungarian, whereas I *do* see a downside.

No. I have no onus to convince you at all.

Let me see if I can make this plain, since you don't seem to get it yet:

My contribution here is not intended to sway people to the side of
Hungarian. I couldn't care less who uses Hungarian, and whether people
like it or not.

That may be the case - it's not the impression you give, however (going
back to the whole impression vs reality point).

Rather, my point is simply that the only arguments presented here against
Hungarian have been based solely on an incorrect understanding of
Hungarian. Why bother to argue against something if you aren't going to
bother to get the facts right?

The arguments I've presented against using Hungarian have been on the
basis of it being harder to read without a significant amount of
getting used to it, and that that effort isn't worth it until a benefit
has been demonstrated.

Which part of that argument is based on an incorrect understanding of
Hungarian?

I'll add to that that it requires a fair amount of memory of the tags
to use, particularly if (as it sounds) you have a large set of them to
use, differentiating between Win32 threads, instances of .NET threads
etc.

I would have the same objection if someone argued against using VB .NET by
claiming that the .NET Framework runs slower with code written in VB .NET,
or if someone argued against driving to France from England via the
"chunnel" by claiming that your tires would melt because you get too close
to the core of the Earth. It's not that I really care how someone decides
these patently subjective issues, it's just that I feel strongly that any
such decision should be based on correct information.

Agreed - but I don't believe I've presented invalid arguments. I
believe earlier posters did, but that's not my fault

I don't "put it down" to anything. That's not my place to do.

The fact remains that when using Hungarian, I code faster, more correctly,
and find that my code remains more consistent over time than using other
naming conventions. The proof IS in the pudding, for me. It's my opinion
that someone who rejects Hungarian ought to at least learn it and try it
for some period of time before deciding it's awful.

I've read a lot of code using the bastardised version, and I know I
find *that* appalling. I suspect I'd be more amenable to the "proper"
version, but I still don't see the point of going to effort to learn
something new and train my brain to read in a different way when the
supposed benefits don't have much weight with me.

Out of interest, you say you've been using Hungarian for 20 years - so
when was the last time you tried a non-Hungarian convention for some
period of time? You believe that your code is more consistent than
using other naming conventions, but that belief should be based on
experience of other naming conventions. Have you genuinely tried
others, recently?

That said, I grant that the entire world is filled with people who
prejudge. Even just looking at the computer world, it is filled with
people who prejudge. They argue in favor of their favorite software,
their favorite hardware, their favorite coding standards, their favorite
data structures, their favorite file formats, mostly based on invalid
information.

Frankly, I probably wouldn't have even written anything here except for
the fact that the claims about Hungarian have been so obviously wrong that
it's fairly easy to pick holes in them. I quickly tire of what
essentially amount to religious arguments, and most of the time stay out
of them altogether. I guess I'm just frustrated to see the same old
anti-Hungarian falsehoods showing up here over and over again.

I can understand that - I just don't feel I'm guilty of them myself.

So mark me down as "can't help myself", but at least for now I think I've
written all that I feel motivated to write about Hungarian. Open-minded
people who have been reading this will take the initiative to actually
learn about Hungarian, to try it for some time, see how it helps them when
they've really learned it. Others won't. Either way, it's no skin off my
nose.

Given so many things in the world to try, I think there are other
things I can put my "learning time" to which I suspect will give me
greater benefits. I suspect you'll have no problem with that though.
There are always going to be plenty of things we can learn - sometimes
we'll waste our time, sometimes we won't.

 

[Peter Duniho]

[...]
It doesn't directly create bugs, but I believe that less easily
readable code is likely to have more bugs than more easily readable
code - as well as being harder to maintain, of course.

But it is only your opinion that Hungarian results in less-easily read
code. My experience has been the opposite. It is harder to read code
when variable names do not follow a consistent, well-defined style like
Hungarian offers.

[...]
I'm genuinely interested in the answer to my earlier question - just
how many tags do you use?

As many are needed. The point is that, because Hungarian is in use,
anyone reading my code knows that a given tag *always* means the same
thing anywhere they see it in the code.

[...]
Could you state exactly which statement I've made is incorrect? I
completely agree that those who have stated that it's to show the
*declared* type are incorrect (with regard to Simonyi's original
intention)

You wrote:

"I believe that variables should explain their semantic
meaning anyway, without requiring prefixes. I don't need
wgt and hgt to mean weight and height - if I have a field
which has something to do with someone's weight, it will
be called "weight" or something equally descriptive."

In the space of that one paragraph, two incorrect implications about
Hungarian are made. One is that the type tag is a prefix, which it's
not. A prefix in Hungarian has a very specific role, completely
independent of the type tag. The other is that one must choose "wgt" and
"hgt" as type tags for those variables, when in fact one would not (as I
pointed out in my first reply to that message).

I reiterate - I don't believe I've written anything incorrect about
Hungarian. I've given a less-than-brilliant example, but that's about
it, I believe. (You misinterpreted my example, by the way, certainly
due to me not being very clear - I wasn't suggesting that "hgt" and
"wgt" would be the full variable names, but prefixes.)

See above. Even with the clarification, your understanding of Hungarian
is flawed.

That's a very fine line, and one which I don't believe stops the
implication from being insulting. "When did you stop beating your
wife?"

Well, be insulted if you prefer. I suppose that's your prerogative as
well.

(You also haven't always been on the same side of the line. For
instance, the statement "Yours IS a simplistically incorrect perception
of Hungarian" is not a statement about the impression I give - it's a
definite statement about my perception, isn't it?)

It is not. If you would care to look at the context in which that
statement appeared, the "perception" to which I refer is that exhibited in
the text that I quoted. And that text definitely does demonstrate a
simplistically incorrect perception of Hungarian.

Again, be insulted if you prefer, but I think it would be better to spend
your time reconsidering how you characterize Hungarian.

Funny, as that *appears* to be what you've been trying to do. I don't
believe I have anything to "deal with", as I don't believe I have a
problem.

You have a problem if you recommend against OTHERS using Hungarian without
fully understanding it yourself. It's well and good for you to make that
uninformed choice yourself, but you should not be making recommendations
to others when you don't have the knowledge and experience necessary to
make an informed choice.

I disagree. While everything might require *some* training, I believe
the *level* of training is significant. I believe it takes less
training to become comfortable with "delayInMs" than "msDelay".

The problem is that that's just one example. Hungarian deals with a wide
variety of issues, and makes improvement in all of those areas. The level
of training required to be familiar with Hungarian is minimal, and the
benefits significant.

[...]
I'll add to that that it requires a fair amount of memory of the tags
to use, particularly if (as it sounds) you have a large set of them to
use, differentiating between Win32 threads, instances of .NET threads
etc.

Conversely, if you do NOT have unique ways to identify those different
kinds of data structures when not using Hungarian, then your code is
ambiguous to the reader. That's my point.

You use as many type tags as you need, no more, no less. If an alternate
coding convention has fewer unique identifiers, then by definition it's
ambiguous. If it has the same degree of uniqueness or greater, then the
complaint of "too many tags" is hollow.

[...]
Out of interest, you say you've been using Hungarian for 20 years - so
when was the last time you tried a non-Hungarian convention for some
period of time? You believe that your code is more consistent than
using other naming conventions, but that belief should be based on
experience of other naming conventions. Have you genuinely tried
others, recently?

Yes. Every time I play around with sample code or help someone with their
own code, I attempt to follow the conventions (whatever they are) of that
code. It's very unusual for those instances of code to follow the
Hungarian conventions.

In addition, I had been coding without Hungarian for at least 10 years
prior to learning about Hungarian. I still remember the headaches of
trying to keep track of what all of my identifiers really mean, reliably
and efficiently reviewing code for correctness, and of even trying to
figure just what to call something.

I have plenty of experience with all manner of coding conventions, and
every time I am exposed to non-Hungarian code it simply reinforces my
choice to use Hungarian.

By the way, check out www.ps2pdf.com to convert that Postscript file to
PDF, if you don't have any thing on your computer that will natively
display the Postscript and want to read Simonyi's original thesis.

Pete

 

[Jon Skeet [C# MVP]]

<snip>

I suspect we're not going to make any actual progress here.
I'll read the links you posted, and if I ever find I've got time on my
hands (which I pretty much never do) I'll give it a try - but for the
moment, I still believe that Hungarian notation interferes with my
natural way of mentally reading code out loud, which is a significant
hinderance to me. (That's a personal preference due to the way I read,
and may well not affect many other people.)

 

[Barry Kelly]

But it is only your opinion that Hungarian results in less-easily read
code.

That's a pretty strong statement. I agree with Jon, so he's not alone.

My experience has been the opposite. It is harder to read code
when variable names do not follow a consistent, well-defined style like
Hungarian offers.

Consistency is not exclusive to Hungarian Notation. I use a consistent,
well-defined style, typically post-fixing my names with a semantic unit
where necessary - e.g. currentWeight, currentHeight, for the example
earlier in this thread.

-- Barry