Best practices for C# GUI naming conventions? [clo

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?

Answer 1

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 2

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

Answer 3

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 4

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 5

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!

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