Greg picks up on a thread from Jason Haley about UI control naming conventions, then goes on to argue for hungarian notation (i.e, txtFirstName vs. firstNameTextBox).

The problem with this is, it's not hungarian notation. The original reason behind HN was to denote the purpose of a variable, not its type. This may come as a bit of a shock to the 14 bzillion VB programmers out there who have been txt'ing and lbl'ing their way through life.

If you want to have a really intelligent explanation, go visit Joel Spolsky's article on making wrong code look wrong. About 3/4ths of the way down the page is the heading "I'm Hungary" (typical Joel fashion). That's about the most succint explanation I've read on the matter. The whole article is quite good, actually.

So, back on my point, txtFirstName isn't hungarian. Technically, the purpose is an input field that holds a name; in this specific case, the first name. So if you want to get picky, I would propose something along the lines of inFirst. The in- prefix denotes that this is an input field for names, and this in- deals specifically with the first name. This is more in the vein of hungarian notation than txt.

Lets take another example. Suppose we are writing an application that needs to take a date for some bizarre reason (oh, say like date of birth or someting crazy like that). The initial draft of the application starts out using a text box. With (my interpretation of) proper hungarian notation, you would name it something like idBirth.

Now some weirdo UI/UX guru floats in on his carpet and says you should really use a date/time picker style control. All you have to do is swap the implementation of the control, not the name. The name still stands, and makes perfect sense. You don't have to replace any code that references the object, and you're seen as a pragmatists pragmatist.

The sad reality in this is the lack of proper OO design on UI controls means I use the Text property to get the value of the text box, and the Value property to get the value of the date/time picker. When you consider you actually write and speak about input controls having a "value", wouldn't it make more sense? Anyway, just a personal pet peeve. There's nothing to stop us from subclassing the relevant controls and providing a more harmonious interface, code wise.

And, after all that explanation, I still prefer the AttributeComponenttype naming convention as it reads more naturally, and you shouldn't be exposing your UI controls to business logic anyway. I mean, come on! What planet are you on?..