Best practices for C# GUI naming conventions? [closed]

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

Toxicology

"textBox1" is only "as bad as you can get" if you actually reference it in code. – Bakke

@Austin: In that case, WinForms you should have Generate Member set to false, and XAML you should not define the x:Name at all. – Toxicology

sorry there is no good anser to this, I like textBoxName and lableName myself but find it hard to defend. – Uptake

I agree with Guard, the generate member should be set to false by default. In fact, I go through and manually set it to false on anything that i am not explicitly using. – Washtub

Arguments for NOT using hungarian notation here: #112433 – Claxton

possible duplicate of textBoxEmployeeName vs employeeNameTextBox – Pith

@Pith It was a little more generic wording, although now (3 years later) this question should probably either be closed due to it's subjective nature, or locked to prevent any more answers. The duplicate Q was looking for "What do you use?", I was hoping for best practices in a 'Code Complete' style justification, but ended up getting the same thing. – Toxicology

@Claxton regardless of if you agree with that post or not, I'd opine that there's a fairly large difference between naming a string or numeric variable versus a control object. – Aligarh

Answer 1

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

Barbary

Agreed. This is virtually the only thing I use this syntax for anymore, and it's simply because of the disconnect between usage and declaration caused by the partial classes for the designer generated stuff. – Monopetalous

Is there a resource perhaps showing "correct" prefixes for controls? For TextBox I see txt, tb, and tbx so I'm never sure what's right. – Toxicology

@Neil: why the need to abbreviate? It takes more work to (keystrokes) to rename button1 to btnUserEmail than buttonUserEmail. I absolutely agree with your logic, but txt is not the type of the control; textBox is. – Washtub

That MS support article only lists VB4/VB6 languages in the "Applies To" at the end. Maybe not the best reference for modern .NET development. – Petterson

This is what I use for naming convention, but I think the most important think is that every developpers in the team use the same! – Soliz

I would rather use userEmailBtn as I can then type "userE" and get a usefull list form msDev, also then related text boxes and lables are sorted next to each other. – Uptake

I so somewhere in SO recommended to use more implementation independent approach - in this case it would be UserEmailButton, or UserEmailSelector (for listbox, combobox, etc) or UserEmailInput (for textbox). I think this is more intuitive – Banerjee

Answer 2

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.

Suzettesuzi

Beautiful explanation. What would you do if you had a name class (BigNameClass) that contained parts of a persons name (prefix, first, last, middle initial, suffix) Would you then use fullNameBigNameClass? A hard part in creating a standard, is where to draw the line on this type of decision. – Braid

Thank you. And yes, I've run into this exact problem. Most things that fall into the category of "BigNameClass" tend to be of the pattern "AdjectiveAdjectiveAdjectiveAdjectiveNoun". So I tend to reduce it to something like "fullNameNoun" or "fullNameAdjectiveNoun" ... just as I reduced "MailAddress" to just "Address". – Suzettesuzi

+1. This is the way I do it and feels nicer :) – Decima

How about control based fields and parameters? – Flue

Answer 3

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.

Cry

Answer 4

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.

Permenter

Answer 5

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

Wilkison

+1 for linking Microsoft's .NET naming recommendations. – Petterson

Answer 6

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.

Smokeproof

I agree, otherwise you run the risk of txtName actually being a combobox, etcetera. – Crackbrain

Answer 7

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

Aimless

This is what I follow except I tend to make the first letter lower case, simply because I find it more pleasing to the eye. So for me it'd be textBoxName – Steffy

This convention is helpful because it effectively puts GUI objects in a separate namespace from other fields. My login code probably has several variables named userName or password, but there's no confusion with TextUserName and TextPassword. – Thermel

This doesn't make sense to me because in English we prefer AdjectiveNoun. For example, UserName, not NameUser. So a TextBoxName would be the name of a textbox (it is a name, or noun, of type TextBox). NameTextBox is correct: it's a TextBox of type, or for, Name, just like UserName is a Name of type, or for, User. – Courtmartial

@Courtmartial maybe that's for intellisense purposes? if you type TextBox, txt(or what suffix you prefer) you can see all your textbox controls from there. – Weingartner

@Hacki Yes, but that's only one possible way for meaning to be organized. Maybe you find it useful to organize ALL your symbols by the type of control they reference, but then you completely lose the ability to sort by another value. What if you want to have NameTextbox, NameLabel, NameEditButton, and NameActiveCheckBox all sort near each other? There is no automatic win to see all textbox controls together. It depends on what you value. I don't value the type of control much at all—I value the semantics of what it's FOR. – Courtmartial

Answer 8

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'

Bethune

Answer 9

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.

Braid

Answer 10

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.

Achaea

Answer 11

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?

Petterson

But then what's the alternative? – Toxicology

Personally I name a textbox for what it's for: name, username, password, etc. Unless it collides with some class member, then add a suffix like: nameTextBox or nameInput. – Petterson

Is this sarcasm? Visual Studio does name controls by type when you add them to a form. – Thermel

Answer 12

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

Soliz

Answer 13

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

Kisser

Answer 14

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

Bakke

Answer 15

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.

Gunning

Answer 16

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!

Modigliani

Answer 17

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.

Variolite