Fog Creek Software
Discussion Board

Welcome! and rules

Joel on Software

The death of Hungarian Notation?

I'm moving over to C# from a 'classic' VB background.  In the past, I've just been stumbling around the wonderful world of dotNet.  Now, however, I'm ready to write a proper production application (my employer won't let me indulge in 'research' forever...).  No more examples, tests or messing about, it's time to write something decent.

Now, I'd like to use a coding style that follows some sort of standard.  I've had a look through the MS naming conventions and - lo and behold - Bill and the mighty software Gods seem to have dropped Hungarian Notation.

Now, I can understand why you wouldn't want HN on anything declared as public - fair enough.  But I see - after a google-expedition - many people seem to have given HN the old heave-ho completely.  Gone, not used, dead.

Trouble is, I (and other members of my team) found HN pretty useful when writing VB code.  I'm pretty easy-going and am receptive to the idea of abandoning HN and using camel/pascal notation with carefully chosen names instead...but the rest of my team are not keen at all.

Can anyone out there think of any reasons I could use to help convince my team to drop HN?

John Fletcher
Wednesday, March 26, 2003

VB wasn't very strongly typed. I can see why HN was helpful there. VB.NET is very strongly typed, like C#, and doesn't really garner much benefit from HN. Some prefer it for printed readability, but it's down to personal preference. Most of the engineers I know don't miss it in the least. Besides, virtually everything you're going to use is an object, not a simple type. :)

Brad (
Wednesday, March 26, 2003

Hungarian notation is obsolete because it is a redundant piece of information that is no longer technically necessary, and redundancy of information just leads to maintenance issues down the road. i.e. You chane the numIdentifier to a string field, etc, and now you have to change every reference to it to reflect the new type. Because virtually all good IDEs make discovery of type a trivial operation (even with colour coding for those so inclined) the extra info wasn't necessary.

With .NET Microsoft nicely did produce a "standard practices" guideline that you can find at


Dennis Forbes
Wednesday, March 26, 2003

Three observations:

1. Your team should do whatever works for your team, unless you're in the business of selling source code to developers, in which case you should pander to the market.

2. Microsoft doesn't have just one policy about Hungarian notation in .NET; you can find samples that use it, and samples that don't, all from Redmond. Many seem to use Hungarian for control names but not for variables.

3. Discussing Hungarian notation in any mailing list or forum is about as likely to generate useful information as calling someone a Nazi.

Mike Gunderloy
Wednesday, March 26, 2003

Maybe you can move to VB.NET instead of C# and spin it as a compromise.  Coming from a VB background, that would be less traumatic anyway.

Wednesday, March 26, 2003

As a C++ programmer I never liked the HN. I understand the benefits of it but, to me, it is just ugly and cumbersome to use it. My preferred naming standard it's the one used throughout STL, simple and pleasant to eye. For instance, instead of using names like "const CString GetName() const" I prefer "const std::string name() const"; one of the big advantages is that it’s much easier to read (as English): if ( == "C++") compared to if (s.GetName() == "C++") and this is a trivial case.

Wednesday, March 26, 2003

Dennis is correct in that one of the major weaknesses of Hungarian _as it is commonly used_ is the redundancy of information.  After all, with "DWORD dwFoo", there is no additional information imparted by the "dw".

However there is a big difference between Hungarian as it is _commonly_ used, and Hungarian _properly_ used.  I never use Hungarian as a way to document the _storage type_ of a variable.  That is already clearly documented!  But Hungarian _is_ useful as a short form to document _semantics_ of variables. 

"DWORD cchNameMax" is an excellent use of Hungarian because it tells you in a very concise way what the _meaning_ of the dword is.  The "cch" and "Max" tell you something you don't already know.

Proper use of Hungarian can help find bugs.  For example, one day I took a huge source of bugs -- a module which did string manipulation functions that compiled into Win16, Win95 and WinNT libraries -- and renamed all the variables using correct Hungarian.  A huge number of bugs suddenly became completely transparent -- any time a "cch" (count of characters) was added to a "cb" (count of bytes) I knew immediately would be a bug in the Unicode flavour.

I don't care whether you use Hungarian or some other system, but I strongly recommend adopting some standard system whereby the semantics of variables are represented, not just their storage types.


Eric Lippert
Wednesday, March 26, 2003

I wonder if its because .Net writes lots of the code along the way and it was easier to drop HN than build something that could be template driven to cater for different styles used by different companies.

Some more thoughts...

Thursday, March 27, 2003

Thanks for all the comments.

I hadn't realised this had already been covered in a previous JoS discussion (that'll teach me for not using the search facility...).

We need to stick to C# rather than VB.NET as other teams in the company have already adopted C# and I'd like to share code between teams (incidentally, the other major team which has a code-base I'll be raiding do not use HN).  I don't want to mix and match dotNet development languages as I think it's bad enough that the team have to learn C# and will eventually have to dive into JavaScript, HTML, DHTML and ASP.NET (that's going to be a shock for them after years of classic VB!).

Personally, I'd like to drop HN completely, but I can foresee a bit of a struggle to convince the rest of my team who have strong opinions on using it. 

Perhaps if they're really in favour of it, I should get them to draw up a list of the conventions they would like to use.  I can't see a great deal of value in learning a set of distinct prefixes for sbyte, short, int, long, byte, ushort, uint, and ulong!  And then there's float, double, decimal...

Since C# is object-orientated, everything is an object (sounds nice and simple).  So I can't see how someone could draw up prefixes for all the different types of objects.  And prefixing them with - say - 'o' or 'obj' is then rendered meaningless.

Hmmm...that gives me a few ideas, anyway.

Thanks again for your help!

John Fletcher
Thursday, March 27, 2003

I agree with what you're saying, Eric, however I think you're mixing Hungarian Notation, traditionally a method of prefixing with type (i.e. dw, p, etc.) and context (whether a variable is local, global, const, etc.) coding, with proper variable naming. i.e. You may call your use "proper", however the general industry does not : Hungarian notation is not defined by making an acronym for a proper variable name.

In any case the problem with such a system is that it depends upon a "system" of standards, and the nice thing about standards is that there's so many to choose from. What do I mean by that? I mean that if you have a team of developers, and each has a set of special "correct" acronym prefixes to define the purpose of a variable, the system is worse than having no system at all: How many workplaces have developers with too much time on their hands who propose an all new system of code "standards" that doesn't follow any of their historical code? In the end they end up with a codebase that is a cluster of 20 different "standards" that all made a lot of sense in a particular point in the curve of philosophies and technologies.

In the end this is all about proper variable naming. i.e. stringByteLen, stringCharLen, memberCount, etc.

Dennis Forbes
Thursday, March 27, 2003

I'm glad we agree -- clearly the important thing is that names be generated in a manner which improves code clarity, no matter what system is used. 

That doesn't mean I won't quibble though!  I haven't seen a conversation about Hungarian that was not full of quibbles over trivial points yet, and I'm not about to be the first one.  :-)

The misunderstanding arises directly from the worlds worst and most widely read text on Hungarian -- Petzold's book.  In his book he mentions nothing whatsoever about use of Hungarian for _anything other_ than duplicating information in the type declaration.  Petzold _thoroughly misrepresents_ Simonyi's system, reducing it (as you correctly say) to a pointless redundancy.

Simonyi had the exact _opposite_ in mind when he designed his system (and it amazes me that four editions later, Petzold has not updated his misleading text!)  As Simonyi said in his original paper

"[my notation's] definition of 'type' is a superset of the more common definition which takes _only_ the quantity's _representation_ into account."  (My emphasis)

Simonyi goes on to give many examples of suffixes and prefixes, _all_ of which denote operational semantics.  Yes, some also give storage type, like "b", but clearly Simonyi is advocating that his system be used primarily as a way to _extend_ the type system from mere storage to operational semantics.

If you're interested in the original paper, you can find it here:


Eric Lippert
Wednesday, April 2, 2003

*  Recent Topics

*  Fog Creek Home