Farewell, beloved Hungarian Coding.

Today, is a memorable day for me. This morning I had to bite the bullet: get rid of my Hungarian Coding style in C#. Not because I hate Hungarian Coding, on the contrary: I love it, but because I have to. The reason for this is that when you want to sell a library which targets .NET, you simply can't feed your customers a library with interfaces which use input parameters like cmdCommandToExecute or efEntityField. I did convince myself when I started this project, it was my code and I should decide how the interfaces looked like. But this is just plain stubbornness. A customer doesn't give a you-know-what about the zillion + 1 reasons you can bring to the table why you had to make the interfaces of the classes inconsistent with the rest of the classes used in the application (f.e. the .NET classes).

Does it hurt? Well, a little. I'm still convinced Hungarian Coding is necessary. F.e. I had an input parameter 'iOperator'. You can't change that to 'operator' because that's a reserved keyword. So you have to come up with another name for a parameter that's perfectly described with 'operator'. Member prefixing is another advantage, however you can also have that with your caMel cased members, f.e. by using a '_' prefix. Microsoft avoided every guideline for private member variable naming, and if I have to guess I think the reason for this is that with a prefix you can use the same name for a member and a parameter which supplies the value for the member in a constructor or method, without forcing you to come up with 2 names for the same value.

I'll miss it though, as I missed my own scheme when I switched to Hungarian Coding back in 1995 (doing C++ work is driving you towards Hungarian Coding, like C# is driving you to PasCal /caMel casing). I already fear the Cold Turkey syndrome I expect when I re-read my own code without a type prefix in sight. *iShiver*

7 Comments

  • Don't throw it all away ;-)





    While I love to use (more VB-style than hardcore C++) hungarian notation, I completely agree with Microsoft's view on how public stuff should be named. So all my public interfaces look the "Microsoft way", internally I use HN. Nice feature: Parameters are easy to spot inside the code of a method because it doesn't use HN unlike the other local variables.





    Roland


  • That's what I did for an hour of converting interface code (I have already thousands of lines of code of this library with HN, waiting any longer would only be stupid) but it doesn't look right to me. I see your point, however for myself it was harder to get rid of the habit to write HN code when I kept local variables HN style. It's a matter of getting used to I guess. after another hour of refactoring it doesn't hurt my eyes that much anymore. :)

  • In the devteam I work in, everybody uses the mixed HN/non-HN approach. Comparing source code of other team members (with HN used internally) with sample code from the Web (no HN at all), I must clearly say that the code without HN is harder to understand (note that this is also valid for code that is not related to our everyday work, otherwise the comparison would be biased). The worst problem is finding the difference between local variables and private data members (if people don't use the "_thisIsPrivate" notation).





    There is one huge advantage of HN that I don't see mentioned often in discussions: Intellisense. Typing the first characters and then invoking Intellisense will filter the entries shown in the drop down list very nicely (e.g. "m_" for all private members, "str" for all local strings, or "m_str" for all private string members). I even add a specific prefix for controls on a winform: "c_" (followed by a VB-style lvw for listview, lbl for label etc.).


  • If you want to do it totally correct, you should use this.memberVariable instead of just 'memberVariable'. It's a bit of extra typing, but makes it more readable IMHO (but because I'm now in HN-Rehab I'm not in that phase yet ;))





    The intellisense argument is definitely true, in VB and C++ it's a real timesaver, however with the mixed api naming schemes in .NET it gets a bit messy IMHO, also with VS.NET 2003 the most used name is picked first, which saves you even more time.





    Your point about the control prefix is a good one, if you look closely at MS' own contradicting documents they mention a prefix for a textbox or button control here and there. I'm not sure what I'll do about that, btnOK is very logical. Just having 'ok' as variable isn't telling me anything.





    Also the different typed variables which are very closely related to a single item are now harder to formulate: sometimes you have 2 variables of different types holding the same semantic value in different type formats. You can do that easily with HN, you can't with this caMel/PasCal casing. I do get the feeling though you are forced to think deeper about a name for a variable, which is a good thing IMHO.

  • > I had an input parameter 'iOperator'. You can't change that to 'operator' because that's a reserved keyword.





    In C# you can escape reserved names with an '@', so you can define your parameter as @operator, and users of your library will see it as operator.





    Fernando Tubio


  • hmm ok, didn't knew that, thanks. I think I stick with my new name for operator though. :)

  • I was a strong proponent of using the "this->" convention for C++, but with C#, I don't see the point. There are no free functions, so you are either referencing a member function or a function in another object. So saying this.DoSomething() no longer adds a lot of extra readability/information for me.





    I am torn on the notation subject. I don't, and never have, liked Hungarian to annotate the type of variable referenced. But I do like it to indicate purpose. m for member, a for local, in for input parameters, out for output parameters, k for constant, s for static. These add meaning and context to me. Dropping the a for local is not a big deal to me, but when I loose the context of input, output, and members. Then I start to have more of an issue.





    I try to work both ways to get myself used to no prefix context. But it does hurt.

Comments have been disabled for this content.