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!

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.

Show quoteHide quote

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.

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

On Tue, 20 Mar 2007 12:26:20 +0800, Shawn B. <lea***@html.com> wrote:

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/microsoft.public.dotnet.framework.windowsforms/browse_thread/thread/cadbc77928d7be28/5b50312c2cdda10c

Pete

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.

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.

Show quoteHide quote

On Wed, 21 Mar 2007 11:02:13 -0700, Cowboy (Gregory A. Beamer) 
<NoSpamMgbworld@comcast.netNoSpamM> wrote:

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

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.

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.

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

Peter Duniho <NpOeStPe***@nnowslpianmk.com> wrote:

<snip>

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.

On Wed, 21 Mar 2007 13:15:07 -0700, Jon Skeet [C# MVP] <sk***@pobox.com> 
wrote:

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.

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.

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.

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

Peter Duniho <NpOeStPe***@nnowslpianmk.com> wrote:

<snip>

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.

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

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.

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.

On Wed, 21 Mar 2007 15:00:03 -0700, Jon Skeet [C# MVP] <sk***@pobox.com> 
wrote:

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.

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.

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.

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.

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.

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

Peter Duniho <NpOeStPe***@nnowslpianmk.com> wrote:
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.

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 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...

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?

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.

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?

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?

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.)

On Wed, 21 Mar 2007 16:17:03 -0700, Jon Skeet [C# MVP] <sk***@pobox.com>=
  =

wrote:

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 mea=
n  =

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 ide=
a  =

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.

I make no attribution.  How could I?  I have no experience with your cod=
e,  =

or your development style.  It would be foolish of me to assert anything=
  =

one way or the other about how YOU code.

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 chanc=
es  =

that such a bug does not exist seems extremely low to me.  Certainly wor=
th  =

betting on.

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

I don't know.  How many bugs have you documented throughout the entire  =

development cycle?

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

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 de=
al  =

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=3D/library/en-us/dnvs6=
00/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 res=
t  =

of the notation can be used unchanged; prefixes and suffixes in particul=
ar  =

still apply just as well as they always have.

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 refra=
in  =

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 made no such claim.  I simply pointed out that what's been written her=
e  =

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.

This is the only valid reason of the two, and frankly that's something y=
ou  =

need to deal with on your own.  I don't see it as my role to convince yo=
u  =

to use Hungarian.

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.

Of course it would.  It would be foolish to think anything a good idea i=
f  =

it didn't provide some benefit.  Duh.

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 agains=
t  =

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 .NE=
T,  =

or if someone argued against driving to France from England via the  =

"chunnel" by claiming that your tires would melt because you get too clo=
se  =

to the core of the Earth.  It's not that I really care how someone decid=
es  =

these patently subjective issues, it's just that I feel strongly that an=
y  =

such decision should be based on correct information.

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 correctl=
y,  =

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 opini=
on  =

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 th=
at  =

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'v=
e  =

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 wh=
en  =

they've really learned it.  Others won't.  Either way, it's no skin off =
my  =

nose.

Pete

Peter Duniho <NpOeStPe***@nnowslpianmk.com> wrote:
Show quoteHide quoteWell, 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.

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?

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.

Well, it would demonstrate your point...

Plenty (I won't give figures here just in case management are sensitive
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.

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

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

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 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.

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

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.

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.

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.

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

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.

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

Show quoteHide quoteI'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?

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

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.

On Thu, 22 Mar 2007 00:44:28 -0700, Jon Skeet [C# MVP] <sk***@pobox.com> 
wrote:

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.

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.

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).

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

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

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.

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.

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.

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.

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

Peter Duniho <NpOeStPe***@nnowslpianmk.com> wrote:

<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.)

Peter Duniho wrote:

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

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

Simple problem: Why does this cause a massive memory leak?
how to control UDP sending Speed?
How to handle this exception?
What is WPF equivalent of the open folder dialog of WindowsForms?
BLOB problem
Using Generics vs Passing System.Type as argument?
.NET Speech Recognition
handle leak - hotfix availability
intercepting the CLR
Anonymous method