I think the main distinction in naming is between logic and view-related objects. You might have a variable named “UserName” in the code behind file of a page, but then also a .NET TextBox in which a user is supposed to enter their username (a sensible ID would also be “UserName”). How can we differentiate (ID-wise), between the logic “UserName” and the view “UserName”. My question is, what is a sensible distinction to make when coming up with these names?
In my opinion, a variable name/control ID should never describe what it IS, only what it DOES. “tbUserName” describes that it is a TextBox, “strUserName” defines that it is a string.
One idea would be to prefix all view related objects with “vwUserName” and keep the logic part as “UserName”. Does that make sense? What about when we have a situation where you have validators? Would you name them “vwUserNameRequiredValidator”, or “vwEmailAddressFormatValidator”? In that situation would you need to describe what it actually is? Would you give a .NET RequiredFieldValidator object an ID of “rfvUserName”?
I really want to get an idea of what other people think on this, because I want to come up with a sensible and consistent naming convention system going forward. I’m interesting to hear arguments for any type of system.
Hungarian notation is so 1990s… 😉
I would use UserName for logic and userName for id.