I review a lot of computer books, both here and for other clients, and I've noticed that one of the changes in programming practice recommended by Microsoft in the "After .NET" era just isn't being picked up on the radar of authors.
(Maybe we should start a new calendar: "PN" for "Pre .NET" and "AN" for "After .NET". That would make this the year 3 AN.")
The change is that Microsoft no longer recommends Hungarian prefixes for variable names. For those who are unfamiliar with this style, variables like txtInput or intCounter use Hungarian prefixes. The most recent Visual Basic .NET books I have been asked to review - both still unpublished right now - continue to use Hungarian notation.
Microsoft's current recommendations can be found on these pages:
Visual Basic Naming Conventions
.NET Framework Developer's Guide General Naming Conventions
In the second reference above, Microsoft puts it pretty plainly: "Do not use Hungarian notation." It can't get much more clear than that.
(Although, I note that Microsoft Consulting still recommends it on their page. Microsoft seems to be getting big enough now so that their left hand is losing track of their right hand.)
The basic idea is to give every variable a name that will signal the type of the variable. The justification for doing this is to make sure that a no operations are performed on an incompatible type. This idea is named after Charles Simonyi, the Chief Architect at Microsoft for many years, who was born in Budapest, Hungary. Simonyi left Microsoft in 2002.
Hungarian notation clearly had a place at one time. Performing operations with incompatible types was a major source of bugs when most of the world's really complex code was being done with C++. Today, however, sophisticated editors like Visual Studio 2005 simply flag all such operations automatically. If you want to know what a variable type is, a ToolTip of the definition will display when you rest the mouse over the variable. Or left-click the variable and go right to the definition. It puts Hungarian notation into the punched card era.
Never try to do something yourself that the computer can do better.
Hi Dan,
I would like to point out that there is a huge difference in reading through code and seeing the type of variables in their names rather than having to mouse over them to find out. I am currently refactoring a C# web application project with approx. 300.000 lines of code. There have been many developers before me that implemented the code in it, each one in their own style. Reviewing code by someone who used hungarian notation is significally more efficient and meaningful. I tend to use keyboard shortcuts for all that I can..but having to reach for the mouse all the time just to see the types of variables is not saving me time. The alternative would be to jump to the origin of the variable with F12..(btw which does not always work correctly in VS) but jumping back-and-forth in code to see the type is very time consuming. Also when hungarian is used the variables are more unique throughout the project, e.g. reviewing code often involves investigating the “business model” of the code and when searching for instances of the variable “currency” throughout the project (Ctrl+Shift+F in V.S.) will give you hundreds of results… so no help in that. But if I was searching for “txtCurrency” I would get about 5-10 results. The intelligence in V.S is also more efficient as the underlying indexer has more variety of variable names. Some say Hungarian notation makes code hard to read. My guess is they have never learned to read Hungarian notation, to Me Greek is hard to read. But if you take the time to learn it, it makes code that much more readable. So structuring your code with hungarian notation is not all about avoiding performing operations with incompatible types but to make reading through code easy and meaningful and save time.
Very intersting! Thanks for your comments. It seems clear that in your case, Hungarian notation does pay off. Perhaps I should have paid closer attention to Microsoft’s Brad Abrams when I wrote, “Hungarian notation – I’d stress that the ban on these is for publicly exposed APIs.. I am going to stay clear on the religion debates about how you format your source code.”
You state that you’re “refactoring” a large application. “Refactoring” isn’t an activity that has a precise definition. I’d be interested in understanding more about what this involves in your case.
There seems to be two major reasons why Hungarian notation works for you.
1 – You use the keyboard a lot and the mouse is normally used to take advantage of Intellisense type definitions.
2 – The addition of type prefixes adds a little more uniqueness.
For the first objection, your metaphor about “Greek” makes a lot of sense. Once you learn to do something in a particular way, other ways of doing it seem inefficient. I have a hard time imagining that not using a mouse for the type of intense study that I think of as “refactoring”. But whatever works for you!
In the second objection, however, I go back to Microsoft’s statement that names should “favor readability over brevity”. Your example, “Currency” seems to emphasize brevity. If a name was, say, “OperatorEndOfDayCurrency” instead of just “Currency” then you wouldn’t get more than hits than just the specific cases you’re interested in.
Thanks again for sharing!
Hello Gents,
I’m not buying the just don’t do it because we (Microsoft) say so routine.
If for no other reason than disciplined coding standards Hungarian notation is a positive part of a developing a formal coding discipline and in today’s world of large numbers of willy-nilly coders we must have structure and stability.
Humgarian notation is much more readable no matter the case… for example Dan’s example “OperatorEndOfDayCurrency” (shown in HN BTW) is not very clean when in the same case such as operatorendofdaycurrency or OPERATORENDOFDAYCURRENCY but then I suppose you could always use a character such as OPERATOR_END_OF_DAY_CURRENCY (which may or may not get you in trouble in other environments)…
Love it or not I can’t find anything in MS’s advice to prove it to be a sound theory backed by anything other than “Cause We Said So” by Microsoft.
v/r
Chris
Hello, Dan. This post and the comments sent by your readers made me think about the topic. Any change in your opinion since the moment you wrote this post?
By the way, it seems the first link has changed. Now it appears to be located here:
http://msdn.microsoft.com/en-us/library/0b283bse.aspx
I’m a .NET developer and have to disagree with Microsoft on this one. I rarely use Hungarian notation to help prevent illegal operations (the “squiggly” line helps in mostly all cases). However, with the introduction of Intellisense, Hungarian notation helps with providing a subset of the available variables/properties I’m looking for. For example, if I’m looking for a textbox and can’t immediately remember exactly what I named it, I can type “Me.txt” and Intellisense shows me everything beginning with “txt” and I can find the textbox I’m looking for without having to return to the designer. If the textbox were named “DisplayNameTextbox” and I thought I named it “NameTextbox”, then I would have no easy way of finding it with Intellisense and would waste my time in the “N” section.
Ummm … not “Me.txt” … just, “txt”.
But that’s as good a reason for continuing to use Hungarian notation as I have seen.