Dr. Dobb's is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Channels ▼

Matthew Wilson

Dr. Dobb's Bloggers

Hungarian notation alive in .NET?

December 15, 2009

I think - well, I hope, anyway! - that the battle for Hungarian Notation has been resolved for most programmers. Nonetheless, it seems to have left more than a faint trace   in the .NET world. Is this a good thing? Can it be avoided?

[For the record, my opinion on Hungarian Notation is clearly spelled out in section 17.4.1 of Imperfect C++. Basically, I avoid using it to specify the types of variables since that's largely redundant and, worse, is a porting beartrap, but I will occasionally use it in the purposes of variables if I think that it enhances clarity. For example (in C and C++), it can be useful to distinguish between count of bytes (prefix cb) and count of characters (prefix cch) when writing low-level string manipulation functions.]

C# enforces stronger typing than C/C++. For example, you cannot implicitly convert between enum and integer types, which is a great boon! Thus, there's an argument that Hungarian should be even less necessary than it is for C/C++. And, to everyone's great benefit I think, .NET's style does not favour contractions. Thus, we are expected to name our classes NetworkStream, rather than, say, NtwkStm or NetworkStm.

Nevertheless, there's still a lot of Hungarian about. In some of the .NET code that I see, including that in several books (particularly those associated with Microsoft), Hungarian continues to sneak in, albeit to a lesser degree than in Windows programming books of ~15 years ago.

For my part, I've pretty much given up any use of it, except, I find, when doing WindowsForms programming. And herein lies my inquiry: what should one name user interface control variables?

Take the following extract of code from a recent project:

List<Screen> screens in controller.GetScreens(); <br /> <br />. . . // other processing <br /> <br />foreach(Screen screen in screens) <br />{ <br />  lvwScreens.Items.Add(new ScreenListViewItem(screen)); <br />} 

The screens variable is rightly named: it is a collection of Screens, the business objects of concern. Given that, the name for the control, a ListView, that displays the screens cannot also be screens, so I have, out of prior habit, reverted to use of the Hungarian prefix form lvwScreens.

The alternative is to use longer names for both the collection of screens and the display control of screens, but nothing attractive comes to mind: screens & displayScreens, internalScreens & displayScreens, etc., none of which appeal. (I'm reminded of the advice of Kernighan & Pike in The Practice of Programming: "descriptive names for globals, short names for locals", which I prefer to think of (when using languages higher-level than C) as "descriptive names for interface variables, short names for local variables". (Bit less pithy of course, but who uses globals these days?)

Nonetheless, I have a nagging suspicion that I'm suffering from my own mental routine: having determined some years ago that prefixes are viable for some cases, perhaps I am being lazy in allowing myself to use a type-prefix when some other, better naming alternative is waiting to be used.

Any ideas?

Related Reading

More Insights

Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.