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?