Naming conventions: I don’t like camel and I do like Hungarian

This post made me thinking about naming convention in managed code. I tend to disagree with naming guidelines on MSDN since names in them sound names in a typeless language such as Javascript. Hungarian is still useful since it is about code readability in the first place. When in a middle of a long method you see

a = b + c;

is it a string concatenation or sum of two integers? Is a a local variable or a method parameter? Was it passed by value or by reference? At least most people tend to use underscore in front of class member variables, thanks a lot! In short, I don’t mind typeless naming convention (such as camel) in short methods, but I really begin missing Hungarian when reading methods that are more than twenty lines long. “Oh, but methods should fit in a single screen” you might say. Maybe. But in a world of real code they quite often don’t.

So I personally think that as soon as C# becomes as common as C++, rules are going to change 😉

Comments (17)

  1. I second the vote for hungarian, or at least a light version of it. Having type information in the variable name is very helpful.

    I find it harder to do in C#. I wonder if somebody has made some standards yet for doing hungarian in C#. Obviously the pointer/smart pointer prefix is useless.

  2. Drew Marsh says:

    If your variable names are "a", "b" and "c" then you have a bigger problem to solve. 🙂

    If they were "fullName", "firstName" and "lastName" respectively you could be 99.99999% certain they’re strings. Or, in the case of ints even the simple names would work for most of it: "sum = a + b". It’s all about using descriptive names.

  3. I have to agree that using hungarian even helps me keep things straight in my own head as I am writing the code. I guess there will always be different points of view based on guidelines, best practices, common practices, and look-you-don’t-have-to-come-back-and-fix-the-thing-18-months-after-working-on-several-other-projects-so-shut-up-and-let-me-code.

  4. Of course, a = b+c is an extreme case. However, there are plenty of real ones. Take, for instance, collections. How do you tell if it is an array or a list? You may question why do I care, collection is a collection after all. Well, sometimes I do. And anyway, it is still unclear how to tell if varialbe is a parameter or a local? By value or by reference? Is class member static or per instance?

  5. Mikhail, the point you are missing is that hungarian was needed for C/C++ where anything could be cast to anything. With a managed language like C#, there is enough determinism in the language for the dev tools to give you appropriate context. Yes, I can see your point when it comes to reading code in Notepad, but for me at least, I’d rather have code with a longVariableName than code with a g_pcshLongVariableName.

  6. Anonymous says:

    Lazycoder weblog » Amen Mikhail

  7. Tooltips are your friend, if youre confused, just move your mouse to the point of confusion and be enlightened.

    Hungarian is a foreign language, harsh on ther ears and harsh on the eyes. Harsh even on the mind.

    C# is an elegant language, familiar, and yet … so different. How I admire its clean lines and nuances.

    Lets us not bring the hungarian abomination back into our world, having cast it out for what it is.

    If a + b = c is incomprehensible to you, perhaps you should consider another profession.

  8. How would Hungarian help?

    Is na = nb + nc; or sza = szb + szc; any better?

  9. I for one find the guidelines help me produce clear, readable code. You won’t get me going back to Hungarian, not in a million years! 🙂

  10. Matt Hawley says:

    FYI, I code in VB.NET the same as I do in C#, so why must it pertain only to C#, and being as common as C++. Also, in my companies coding standards, we don’t use hungarian notation except for when declaring Windows / Web form elements. All other variables must be self describing, like many have stated above.

  11. Jeff says:

    Hungarian can work if you can get everyone to use the same conventions. The problem is that rarely works in my experience. You make some class called CustomerData and one person will use a prefix of customerData, another cd another custDat and now the notion that you can tell what the thing is by looking at it is out the window. Especially when someone else creates a ChargeDirection class and some use a prefix of cd for that as well. Even if you do get agreement, six months later when a bunch of new objects have been created you have the same problem again.

  12. ANONYMOUS says:

    Why does the name of the variable have to tell you the type? Maybe it should be some other visual cue, like font color.

  13. Ah, yes. Hungarian notation. I tell ya, there is just nothing as good as having a Floating Point variable named intQuantity because a rule changed later on. And how could you not love Columns named [dbMainSystem].[tblOrders].[col_FK_intCustomerID]!


    Ok, so I can see how they may be helpful when doing system programming, but for cryin’ out loud … keep your Hungarian notation out of information systems! 😉

  14. "So I personally think that as soon as C# becomes as common as C++, rules are going to change ;-)"

    Ya…bring in the C++ masses and everything goes to hell, ;).

  15. Oops, hit submit before I meant to

    The other comment: Isn’t it funny that you post about liking hungarian and you get mostly pro-hungarian comments. You post against it and you get mostly anti-hungarian comments. I wonder if it is really as big an issue as many posters seem to make it out to be…

  16. Jeff Atwood says:

    I like hungarian only for simple intrinsic types. I think that’s the best blend of readability and simplicity: