Best practices for C# GUI naming conventions?

GUIs, whether written in WinForms or XAML, seem to have the most widely differing naming conventions between projects I see. For a simple TextBox for a person's name, I've seen various naming conventions:

TextBox tbName      // Hungarian notation
TextBox txtName     // Alternative Hungarian
TextBox NameTextBox // Not even camelCase
TextBox nameTextBox // Field after field with TextBox on the end
TextBox TextBoxName // Suggested in an answer...
TextBox textBoxName // Suggested in an answer...
TextBox uxName      // Suggested in an answer...
TextBox name        // Deceptive since you need name.Text to get the real value
TextBox textBox1    // Default name, as bad as you can get

I abide by the StyleCop rules for all my .cs files normally, and see others do so as well, but the GUI tends to break these rules or vary wildly. I haven't seen any Microsoft guidelines that specifically refer to GUI elements instead of just normal variables, or even examples that would apply outside of a console application.

What are the best practices for naming elements in a GUI?

I use the old school hungarian... txt for TextBox, btn for Button, followed by a generalized word, then a more specific word. i.e.:

btnUserEmail

Have had a lot of people say things like "omg thats so old, VB6 calling!" But in a UI Rich winforms app, I can find and modify things quicker because usually the first thing you know about a control is it's type, then it's category, then get specific. While the newer style naming convention guys are stuck trying to remember what they named that text box.

The original specification for controls is here (archived).

I use:

TextBox nameTextBox;

Just like I would use:

MailAddress homeAddress;

The reason for this is that in these cases "TextBox" and "Address" is descriptive of what the object represents, not how it is stored or used. But in another case like storing a person's full name I would use:

string fullName;

Not:

string fullNameString;

Because "String" is not descriptive of what the object represents, but only how it is stored.

Same convention as everything else in .NET: camel case descriptive name only, optionally followed by a suffix if you need to distinguish different classes for the same logical "thing". For example:

string name; // a name
TextBox nameText; // the control used to edit the name
Label nameLabel; // the control used to label the edit control
List<string> nameList; // a list of names

and so on ad infinitum. It really doesn't matter what the suffixes are as long as they are consistent and descriptive.

This is not my invention, but I like it:

TextBox uxName = new TextBox();
Label uxNameLabel = new Label();
Button uxAccept = new Button();

I prefer this to Hungarian notation since all of my UI controls show up in one block in intelisense. UX for "User eXperience". It's also nice if you change a control from a textbox to a combobox or something, as the name won't change.

I wish someone would become the authority on this subject and just tell it like it is, and start enforcing it... The worst thing to me is when people mix it up in the same application or worse yet same class.

I've see some pretty horrible stuff with txtName, NameTextBox, name and textBox1 all used on the same form... yuck.

Where I work we have a standards document that tells us how to do it, where to do it, and I think only 20% of the people even care to try and conform.

I usually will change something if Fxcop yells at me.

http://en.wikipedia.org/wiki/Naming_conventions_%28programming%29

Capitalization Styles

Note that: Microsoft .NET recommends UpperCamelCase (aka "Pascal Style") for most identifiers. (lowerCamelCase is recommended for parameters).

The most important thing about naming conventions is to choose something that makes sense, get a consensus from all parties, and stick to it like your life depended on it.

As for which convention to use I would vote for this one:

TextBox name

It is short and has semantic value as an identifier. As for the type of the identifier I would rely on Visual Studio to tell you that as it tends to be good at that sort of thing.

I name all my UI elements TypeDescriptor. Following your example, TextBoxName.

I use the Hungation notation with one little difference.

I now work on a project that has quite a rich UI. So finding, with Intellisense, a button called, let's say, btnGetUsers its very easy.

Things get's complicated when the application is able to get users from different locations. That is different controls. So I started to name my controls after where they are located and still use the Hungarian notation.

As an example: tabSchedAddSchedTxbAdress means that txbAddress is a text box where an address can be inserted and is located on the Add Scheduling tab from the Scheduling Tab Control. This way I can find controls very easy and, when I type simply "btn" I don't get, at once, a lot of buttons from all over the user interface.

Of course this is just to help myself. I'm not aware of such a best practice. However it helps a lot.

Mosu'

I've been working with a team lately that is moving from MFC (6.0 ...). There they would have something like

CString Name;
CEdit ctlName;

The easiest way to migrate has been to use something like

TextBox ctlName

It's just enough of a reminder that the variable is the control and not the value of the control.

I think including the type as a part of the name is just OLD.

-- edit -- Another benefit is that all of the controls are grouped together when navigating. If the actual type were used, the ComboBox controls would be quite far from the TextBox controls.

I tend to use c_typeName (please note that type and Name are different), e.g. c_tbUserEmail for a TextBox into which the user should type in his/her e-mail. I find it useful because when there are a lots of a controls, it can be hard to find them in the miles long intellisense list, so by adding the c_ prefix I can easily see all controls in that form.

This Hungarian/VB6-naming insanity needs to stop.

If Microsoft really wanted you to name your controls based on their type then why doesn't Visual Studio automatically tack on the 'txt' or 'btn' when you add the control to your web/win Form?

You have the Guidelines for Names from Microsoft. I dot not follow everything, but it's a good starting point

I use Hungarian notation, that makes easy to find controlls in large pages.

For the elements that I don't plan on using in my code, I just let the designer handle it for me; if they do become something used in my code, they're changed to something meaningful and that happens to be descriptionType (nameTextBox). It's how the designer creates them if given enough information (check out menu items -- "Exit" becomes exitMenuItem).

My own practice is: Type _contextDescriptionType. E.g.:

TextBox _searchValueTextBox

Anyway naming convention is either too personal or imposed by general rules. In any case it should be documented somewhere so that all project developers can easyly access.

I believe naming convention exist to ease the developer coding effort and helps in manageability. To my understand any name which is helpful in easy access should be followed.

I saw number of comments with different approach but the best i found in my projects are to prefix control's 1st three name. There are lots of reason behind following this approach.

1. Intellisense would bring all same type together.
2. Form property windows would also show all same control sorted
3. On complex forms you can easily identify you are dealing with label or textbox (eg. lblAccounts and txtAccounts)
4. A new user can easily deal with coding.
5. Imagine I have accountLst, accountlbl, accounttxt, accountgrd, accountChk controls on same form.

While coding, a developer always knows he is accessing text box or label. Where as he is not clear with what name the other developer has used. So by just writing "lbl" intellisens would bring all the label list to choose, where is if you have used approach used in #5 then intellisense would bring all controls using acc. I rarely saw doing some loop with control name start with "account" or so. This means it would not help in any rare incident.

My bet is to do things which help in understanding code easily for other developer. Because as you grow up in your carrier, you would not always do coding, some other person would come and take your seat.

Choice is yours, which way you want!

If there is a good separation of concerns in an application design, I guess there will be no need for naming buttons as LoginButton, LoginBtn or btnLogin. If the owner of the object is a UI element thus let's call it Login and if the owner is not a UI element then the object is in a wrong place.