Charles Petzold

I see that my good buddy Richard Shaw is giving a talk this Saturday with the provocative title "Hungarian Notation Sucks". I'm tempted to bop up to Mass. and check it out, but we're at Deirdre's house in the Catskills this weekend. (Plus, I have a book to finish.)

Ever since I've been coding in C# and .NET (over five years now) I've been using Hungarian Notation less and less — or at least the type of Hungarian Notation common in Windows API programming and which I see from a quick Google search that many programmers now blame me for propagating. (I sure didn't invent it.) In one of the better articles on the varieties of Hungarian Notation, Joel Spolsky says that it was "spread extensively" by books like mine. I guess that's fair.

I still feel that when perfoming numeric computations using different numeric data types it's important to have the actual data types foremost in mind. The data conversion rules of the C-based languages mandate this concern. And that's why it's often convenient to embed the data type into the variable name.

But this has become less of a issue. I can't remember the last time I wrote an expression that involved a calculation between an unsigned short and a signed long, for example. I can't even remember the last time I used either of these data types at all! In Windows API programming, stuff like that is common, but not in .NET.

For me, the final blow came with the extensive use of double-precision floating point in the Windows Presentation Foundation. When the only numeric data types you're using are doubles and ints, it's usually pretty obvious which is which. So, in the new book, there are no iCount or dAngle variable names. That was an easy decision.

I still use lower-case prefixes for elements and controls — btnCancel and txtboxLastName, for example. I don't know if this is considered Hungarian Notation or not. I understand that it's preferable to name variables based on what they actually do in the program rather than the underlying data type, but when you need to write code like

btnCancel.Click += CancelButtonOnClick;

or

txtboxLastName.Text = person.LastName;

do you really want to "forget" that you're dealing with a Button and a TextBox?

I have found myself renaming variables more, sometimes when the functionality doesn't quite match the variable name, and sometimes when I change the data type. I have Visual Studio's intelligent renaming facility to thank for this new-found power.