Paul Gielens:ThoughtsService

In a world of Intellisensing IDEs and strongly-typed languages, Hungarian naming is a convention which contributes only to making code harder to read. m_dblPrice vs Price.

I have stopped using the Hungarian naming convention primarily for speed and ease of use. I was getting rather tired of every time I decided to switch from using a bool to an int to being forced to find all occurences of that variable and then rename them all. So instead I have just started using regular old CamalCase for my public names and then a hybrid _camalCase for when I have a private property/method. As a result this allows me to easily look through my code and know that if something begins with an Uppercase it is public and if it is lowercase. And as far as telling what the type is, does it realy matter if you choose names that are meaningful? For instance, how many ways are there to interpret what type the variable "FirstName" is?

(offtopic) I mailed you thruogh your blog a couple of days ago, I don't know if it has arrived, but I don't have your email address any more.

I use a modified hungarian approach and it works well for me. MS's suggest works better for public functions, which since .NET is meant for integration, makes a lot of sense. Mine works and I am too set in my ways to change.

Wally

No more hungarian thank you.

Things should be named by concept, no more goblins (g_bln) for me.

For me this means that I will have in an aspx page (where there are often multiple things of the same name) :
FirstName (A textbox)
FirstNameLabel ( A Literal where I put the localized "First Name:"/"Prenom :"
FirstNameValidator ( a required field validator)

The book is wrong period. Its not the convention Microsoft recomends for .NET (check MSDN) nor that they use in the Framework itself. Wrong, wrong, wrong.

Andrew,

Our guidelines are to abide by Hungarian notation for server control names only, but variables and parameters are not be hungarian noted. But I agree, it does become a bit cumbersome if we try to remove Hungarian all the way.

Its fine for UI controls (where I se it too) but no where else.

I guess it's because I am old and grumpy, but I find the idea of changing my naming conventions just because Microsoft says so is idiotic. If yours works for you, why change.
Now that I've alienated everyone I'll say that I use a combination of Hungarian and CamelBack. Public method parameters get CamelBack (FirstName). Internal variables of a method use Hungarian (strFirstName). And private module-level variables use Hungarian with "m_" prepended (m_strFirstName).
I find these advantages
1. I know what the variable type is.
2. I know whether it is internal to a method or global to a module.

Public: Microsoft style
Private: Simplified Hungarian.

One reason: intellisense...

Take a look at the screenshots here:
http://weblogs.asp.net/rweigelt/posts/21741.aspx

I have a sign on my door that says: "BAD API DESIGNERS USE HUNGARIAN". Turns out to be true either way :-).

I still maintain that hungarian notation is a great productivity increase when combined with the auto-completion that the Visual Studio IDE gives you. I save so much time by only having to type the beginning of a variable and hit Ctrl-Space to either fill it in completely or give me a list of possible matches. Especially when you use long descriptive variable names like I do.

m_intAcc(Ctrl-Space)ountExpirationDate

It's great, and it still affords me the INCREASED readability of my code. I can tell at a glance information about the type and scope of any variable.

The whole move toward pascal or camel-cased variable naming seems to me nothing more than a desperate attempt by the VB community to be taken more seriously by the C/C++/C# world by adopting their arguable flawed conventions. To my way of thinking, case-sensitivity and short non-descriptive variable names are a leftover evil that is better eradicated than preserved.

And what's with camel casing anyway. To me it's simple. You're either deciding to capitalize the first letter of each word or your not. Why make an exception for the first word. It's arbitrary and has no logical justification.

make that "arguably flawed"

Objections to not dropping Hungarian:

1) With printed code IDE will not help you.
2) When reading a page of code, you can only get type info on item at a time.

3) MS Complains explains that with Hungarian notation if you change the type of a variable you must also change the name of the variable and this is supposed to be painful. Modern IDEs (e.g. Eclipse... not VS .NET unfortunately) allow you to change names of all occurances of a variables using the IDE ("Refactoring").

I must admin I started to lean against hungarian again... why? dunno... I just got lost in my own app.

I think that MS's reason for dropping hungarian is just to make their public interfaces look "neater" to non-techies.

it's a marketing idea, that is all it is.

Roland Weigelt, in his comment above, links to his page where he shows a very good reason why hungarian is still technically superior, even in an intellisense world. (http://weblogs.asp.net/rweigelt/posts/21741.aspx)

thankfully, too, Visual Studio .Net in Whidbey will include support for "change names of all occurances of a variable using the IDE" (Mentioned by Jon above)

cheers
lb

I think hungerian notations are essential at lesat for controls for making code easy to use for other people than code author

As one of the authors of the book that inspired this discussion, I feel I ought to comment.

The "official" word from Microsoft is to avoid using it, but Hungarian keeps creeping back in. The reason, I think, is that it does have some use. It does have some value.

Even Sam Gentile, who strongly suggests that we are "wrong, wrong, wrong" admits that he uses Hungarian notation for UI controls.

Just for fun, I counted the "votes" that were cast here (this being an election year, after all), and foud the following results: Yes - 6, Maybe - 4, No - 4. So 10 of the 14 people who replied (I'm counting people, not posts!) say they use it some of the time. (I added myself as a "Yes". And sorry, Paul G, I'm not sure from your posts whether you are a Yes, a Maybe, or a No -- so I didn't add you in!).

By my reckoning, then, 71% of those surveyed say they use it. I think perhaps it's time to stop fighting it and use it when it is helpful (and avoid it when not helpful; or not use it at all, for those so inclined).

> As one of the authors of the book that inspired this discussion, I feel I ought to comment.

Its about time ;)

> The "official" word from Microsoft is to avoid using it, but Hungarian keeps creeping back in. The reason, I think, is that it does have some use. It does have some value.

Though they don’t give any arguments for doing so, and this is the thing that bothers me most.

> Paul G, I'm not sure from your posts whether you are a Yes, a Maybe, or a No -- so I didn't add you in!).

I use Microsoft Design Guidelins for Class Library Developers exclusively (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpgenref/html/cpconnetframeworkdesignguidelines.asp). I must admit I have no valid arguments for doing so and in a way feel ashamed of following Microsoft blindly. As a professional I should be more critic about what happens around me but for now I feel like (by seeing the credit lists) a lot of smart people at Microsoft spend a large amount of time on over thinking/documenting these design guidelines. We live in a managed world these days and perhaps its time to move on.