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.