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.

In The Trouble With InputBox, I pointed out that InputBox wasn't really a very good way to input data to a ListBox and I pointed out that it also had a fatal flaw - there wasn't any way to tell the difference between blank input and the Cancel button.

It turns out that this isn't quite true ... About Visual Basic reader "SmetsRoger" pointed out that his whole night school class had worked on this problem and had discovered a solution. I checked it out and, yes, the solution does work ... for now. But I wouldn't use it. The reason it works now and why I still wouldn't use it is a fascinating investigation that you can read about in a followup article, Fixing the InputBox.

Thanks much to SmetsRoger for sending this one in! It was fun!

A reader asked for help coding a loop to input data to a ListBox control. The problem was that the reader was using an ancient holdover from VB6 that still happens to be available in VB.NET ... for backward compatibility. There are better ways and this Quick Tip shows one of them: the Validating Event of a TextBox control. This Quick Tip shows the difference.

VB.NET Shared and Instance Members
Old programmer joke:
There are 10 kinds of programmers. Those who understand binary and those who don't.
There are also 10 kinds of Class members: Shared and Instance.
I was looking for information about this and I found my own article! It answered my questions! But it was a couple of years old so I updated and republished it. Click here to see the result.