This may be a pretty obvious idea, but it hadn't occurred to me before.
W-a-a-a-y back in 2005, I wrote a blog, Hungarian Notation - Good Idea?, in which I noted that Microsoft wasn't consistently recommending a naming style called Hungarian notation anymore. In brief, Hungarian notation names variables according to their type. "txt" would be a text variable; "dbl" would be double and so forth.
If you go back through the examples I code in the articles here, you will see that I have never had a consistent naming sytle. Quite frankly, I name 'em according to the mood I'm in at the moment. I usually use a descriptive name based on camel case: theFirstVar, theSecondVar, and so forth. (In my first programming job with IBM, many many years ago, I can remember using variable names based on variations of the name of the love of my life. That was a good lesson in what not to do. Maintaining the code later was not only embarrasing, it was really confusing.)
That old blog has consistently attracted a comment every now and then over the years and just yesterday, "Matt" left this comment:
"If I'm looking for a textbox and can't immediately remember exactly what I named it, I can type "txt" and Intellisense shows me everything beginning with "txt" and I can find the textbox I'm looking for without having to return to the designer. If the textbox were named "DisplayNameTextbox" and I thought I named it "NameTextbox", then I would have no easy way of finding it with Intellisense and would waste my time in the "N" section.
Good point! Check the graphic above to see how that works.
But the original reason for Hungarian notation was to avoid type conversion errors. Since VB6 declared everything as a "Variant" type, inefficient code and sometimes nasty bugs could be created by thinking you were working with a string when it was actually an integer. VB.NET doesn't have this problem since it features "strong typing". (Although, we're starting to get close to what we had in VB6. I can use "Option Explicit Off" and then simply code myVar = "ABC" with no variable declaration at all.)
It seems to me that, since avoiding type conversion problems is no longer a motivator, you might be better off simply using this idea to group your variables according to some requirement specific to your system. For example, you might have two GDI+ Graphics objects in the same program and you need to make sure that you keep the objects, such as Color, organized.
While Hungarian notation will work on small jobs, it is very difficult to use in large projects.
One problem with it is that if you ever need to change the data type, you have to rename the variable.
For example: you have an integer variable called intCustomerID and you realize a year into production that an integer will not hold all the customer IDs you are generating, you switch to a long. Now every instance of intCustomerID should now be lngCustomerID.
In addition, Hungarian can be hard to read especially if you follow the full notation.
Good points! These are probably reasons why Microsoft doesn’t really push it anymore.
Back in the day, there were name fiends who, yea verily, preached that their favorite method was the savior of programming. These day, people don’t get quite as excited about it.
I do not name variables that way, but I sure do use that naming convention for controls. Like you said, it makes it easy to find and I don’t know about you, but I do not change controls from one type to another very often.
I personally believe some kind of naming convention is good organization. I too use a variant of the Hungarian notation to aid in organizing variables to make them easy to find in intellisense.
Renaming variables used to be horribly error prone since even with Find and Replace you had to be very careful. With some of the great refactoring tools out there now renaming is very easy and safe.
VB6 did not create everything as Variants. Implicit type coercion was a concern but this had nothing to do with Hungarian, which was meant as an aid to code readability.
I think Microsoft no longer recommends the use of Hungarian simply because there is a different “political party” in power now.
I use Hungarian notation for EXACTLY the same reasons your poster Matt does. I keep it simple though. I have a unique prefix for all of the standard controls on forms, and I use prefixes for most common data types.
I say simple because I keep my definitions loose. I don’t typically have the problem commenter Scott claims because all my Integers, Longs, Int64, Int32, etc all use the prefix “int”. I know I’m looking for an integer number. I don’t care about it’s precision anywhere else but it’s declaration.
Most oddball declarations, like custom class objects, I typically dispense with the prefixes and just use a camel-case description. “financeCalc” for the name of a class that does financial calculations for example.
If I have classes I’m very frequently calling in a large project in many areas (especially data classes), I find myself inventing some prefixes just to make my life easier. An example in one project, I have a class that holds and manipulates ink formulation data. Every time I instance a new one, it is prefixed “ink”.
First … Thanks for posting! Sharing our points of view can help everyone be a better coder.
But second …. ummm …. I didn’t quite catch what advantage it is to be able to quickly find all of your “int” variables. Back in VB6 days, there was an advantage because you didn’t want to change the underlying type of a variable inadvertently. Today, the compiler can prevent that from ever happening. So an “int” loop counter and an “int” employee number don’t seem to me to have any useful relationship.
I do think that being able to, for example, group all of the variables in an “employee” structure (say … maybe with an “emp” prefix) might be handy. So the idea has merit, but I can’t see the benefit associated with data typing anymore.
But the concept that has the most merit is, “Think about the naming convention you’re going to use in advance. And if your organization already has one, use it.”
The advantage is simply maximizing the ability of the Intellisense. Let’s say I have a dozen or so “int” variables, some of which are inadvertently sitting at the top of my class since they’re class-scope. I’m typing along, writing the code to some function about 5 screen-lengths away from them. Suddenly, I realize I need to use one, but I forgot it’s exact name. I type in “int” and viola, there’s a list of all my current, in-scope integer variables. I pick the one I’m looking for from the list and continue on my way; without having to scroll up to the top to find the name of my variable and scrolling back to find where the heck I was typing.
Additionally, with all integer-type variables prefixed with “int” it just makes the code easier for me personally to read for some reason. Just glancing at my code, or even a partial block of my code, I instantly know roughly what type of variables everything is. I don’t have, nor need the declaration blocks for them to understand them.
There is a big difference between Apps Hungarian and Hungarian notation (which was based on a misunderstanding of Apps Hungarian, apparently, due to the misinterpretation of the word “type”). Apps Hungarian makes much more sense to me than Hungarian notation does.
Here is a good article about it by Joel Spolsky -> http://www.joelonsoftware.com/articles/Wrong.html
Another thought: System Hungarian was never really necessary in VB, as you could define the type of a variable by its trailing character… if you consistently used one, that is. Coming from a Basic where var$, var%, var&, var! and var# where different variables altogether, I remember simply hating the fact that I couldn’t do that anymore in VB. I found it very easy, since one could use it to remember that var% and var$, for instance, where related to each other somehow.
I’ve read Joel Spolsky’s work a lot in the past but I missed this one. Thanks for posting. I wrote an extended reply, but then I decided that it belonged on the main page, and not just in the “comments” here. So look for it at:
http://visualbasic.about.com/b/2009/12/16/still-hungry-for-hungarian.htm