Best practices for C# GUI naming conventions?

Question

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 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?

Answer 1

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.

Answer 2

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

Answer 3

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

Answer 4

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.

Answer 5

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.

Answer 6

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).

Answer 7

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.

Answer 8

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.

Answer 9

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.

Answer 10

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.

Answer 11

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.

Answer 12

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).

Answer 13

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?

Answer 14

Hi,

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'

Answer 15

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