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
- Anonymous
August 17, 2004
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. - Anonymous
August 17, 2004
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. - Anonymous
August 17, 2004
The comment has been removed - Anonymous
August 17, 2004
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? - Anonymous
August 17, 2004
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. - Anonymous
August 17, 2004
Lazycoder weblog » Amen Mikhail - Anonymous
August 17, 2004
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. - Anonymous
August 17, 2004
How would Hungarian help?
Is na = nb + nc; or sza = szb + szc; any better? - Anonymous
August 17, 2004
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! :) - Anonymous
August 17, 2004
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. - Anonymous
August 17, 2004
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. - Anonymous
August 17, 2004
Why does the name of the variable have to tell you the type? Maybe it should be some other visual cue, like font color. - Anonymous
August 18, 2004
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]!
Gaaahh!!!!
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! ;-) - Anonymous
August 18, 2004
The comment has been removed - Anonymous
August 18, 2004
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... - Anonymous
August 19, 2004
I like hungarian only for simple intrinsic types. I think that's the best blend of readability and simplicity:
http://www.codinghorror.com/blog/archives/000023.html