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

"textBox1" is only "as bad as you can get" if you actually reference it in code. — Austin Salonen, Aug 07 '09 at 19:46
@Austin: In that case, WinForms you should have Generate Member set to false, and XAML you should not define the x:Name at all. — Will Eddins, Aug 07 '09 at 19:53
sorry there is no good anser to this, I like textBoxName and lableName myself but find it hard to defend. — Ian Ringrose, Sep 07 '09 at 14:08
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. — John Kraft, Sep 26 '09 at 20:03
Arguments for **NOT** using hungarian notation here: http://stackoverflow.com/questions/111933/why-shouldnt-i-use-hungarian-notation — gnarf, Jun 10 '10 at 17:30
possible duplicate of [textBoxEmployeeName vs employeeNameTextBox](http://stackoverflow.com/questions/440163/textboxemployeename-vs-employeenametextbox) — nawfal, Jul 21 '13 at 10:48
@nawfal 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. — Will Eddins, Jul 23 '13 at 17:42
@gnarf 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. — Nick T, Mar 31 '14 at 07:04

score 89 · Accepted Answer · edited Dec 20 '18 at 19:52

89

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

edited Dec 20 '18 at 19:52

StayOnTarget

11,743
10
52
81

answered Aug 07 '09 at 19:34

Neil N

24,862
16
85
145

17

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. – womp Aug 07 '09 at 19:45
2

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. – Will Eddins Aug 08 '09 at 14:33
3

@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. – John Kraft Sep 26 '09 at 20:06
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. – Craig Sep 26 '09 at 22:33
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! – Gabriel Mongeon Dec 22 '09 at 18:11
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. – Ian Ringrose Oct 21 '10 at 13:48
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 – Prokurors Jan 10 '15 at 12:21

score 31 · Answer 2 · answered Aug 07 '09 at 19:50

31

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.

answered Aug 07 '09 at 19:50

Lee

18,529
6
58
60

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. – Brad Bruce Aug 07 '09 at 20:09
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". – Lee Aug 07 '09 at 23:37
+1. This is the way I do it and feels nicer :) – Simon Whitehead Nov 05 '12 at 01:16
How about control based fields and parameters? – Yousha Aleayoub May 20 '20 at 14:22

score 13 · Answer 3 · answered Aug 07 '09 at 20:02

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.

score 11 · Answer 4 · answered Aug 07 '09 at 20:23

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.

score 4 · Answer 5 · answered Aug 28 '09 at 20:52

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

+1 for linking Microsoft's .NET naming recommendations. – Craig Sep 26 '09 at 18:48 — Craig, Sep 26 '09 at 18:48

score 3 · Answer 6 · answered Aug 07 '09 at 19:29

3

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.

answered Aug 07 '09 at 19:29

Andrew Hare

344,730
71
640
635

I agree, otherwise you run the risk of txtName actually being a combobox, etcetera. – VoronoiPotato Nov 28 '12 at 21:33

score 3 · Answer 7 · answered Aug 07 '09 at 19:31

3

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

answered Aug 07 '09 at 19:31

Matt Grande

11,964
6
62
89

1

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 – Mark Aug 07 '09 at 19:33
1

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`. – Aug 27 '14 at 18:39
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`. – ErikE Nov 19 '15 at 23:56
@ErikE 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. – paraJdox1 Mar 26 '21 at 08:37
@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. – ErikE Mar 31 '21 at 06:16

score 3 · Answer 8 · answered Nov 10 '09 at 17:26

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'

score 2 · Answer 9 · answered Aug 07 '09 at 19:39

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.

score 2 · Answer 10 · answered Aug 07 '09 at 20:30

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.

score 2 · Answer 11 · answered Sep 26 '09 at 18:51

2

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?

answered Sep 26 '09 at 18:51

Craig

4,323
2
29
32

2

But then what's the alternative? – Will Eddins Sep 26 '09 at 22:13
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. – Craig Sep 26 '09 at 22:29
5

Is this sarcasm? Visual Studio *does* name controls by type when you add them to a form. – Aug 27 '14 at 18:37

score 2 · Answer 12 · answered Dec 22 '09 at 18:14

2

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

answered Dec 22 '09 at 18:14

Gabriel Mongeon

7,251
3
32
35

score 1 · Answer 13 · answered Aug 07 '09 at 19:33

1

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

answered Aug 07 '09 at 19:33

Cleiton

17,663
13
46
59

score 1 · Answer 14 · answered Aug 07 '09 at 19:42

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

score 1 · Answer 15 · answered Aug 07 '09 at 20:04

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.

score 1 · Answer 16 · edited Nov 05 '12 at 01:08

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.

Intellisense would bring all same type together.
Form property windows would also show all same control sorted
On complex forms you can easily identify you are dealing with label or textbox (eg. lblAccounts and txtAccounts)
A new user can easily deal with coding.
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!

score 0 · Answer 17 · answered Jul 23 '13 at 16:54

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.

Best practices for C# GUI naming conventions?

17 Answers17

Linked