Best practices for C # GUI naming conventions?

Question

The GUIs written in WinForms or XAML seem to have the most different naming conventions between the projects that I see. For a simple TextBox for a person’s name, I saw 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 follow the StyleCop rules for all of my .cs files and usually see others doing it too, but the GUI tends to break these rules or vary a lot. I have not seen any Microsoft recommendations that specifically relate to GUI elements, and not just ordinary variables, or even examples that apply outside the console application.

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

Answer 1

I am using the old Hungarian school ... txt for TextBox, btn for Button, followed by a generalized word, and then a more specific word. i.e:

 btnUserEmail 

Many people said something like, “Oh my god, VB6 is ringing!” But in the Rich winforms UI application, I can find and change things faster, because usually the first thing you know about the control is its type, then its category, and then specify. While the new naming style, the guys were stuck trying to remember what they called this text box.

The original specification for the controls is here (in the archive).

Answer 2

I use:

 TextBox nameTextBox; 

Just as I would use:

 MailAddress homeAddress; 

The reason for this is that in these cases, the TextBox and Address describe what the object represents, and not how it is stored or used. But in another case, for example, while maintaining the full name of the person, I would use:

 string fullName; 

Not:

 string fullNameString; 

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

Answer 3

The same convention as everything else in .NET: only a descriptive name for a camel, 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 

etc. to infinity. It doesn't really matter which suffixes as long as they are consistent and descriptive.

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 the elements of my interface are displayed in one block in intelisense. UX for "User eXperience". It's also nice if you change the control from a text box to a combo box or something else, as the name will not change.

Answer 5

The most important thing in naming conventions is to choose what makes sense, get consensus from all parties and stick to it, as your life depends on it.

Regarding the use of the convention, I would vote for this:

 TextBox name 

It is short and has semantic meaning as an identifier. Regarding the type of identifier, I would rely on Visual Studio to tell you that it is generally good at that.

Answer 6

I want someone to become an authority on this issue and just say it the way it is and start applying it ... The worst thing for me is when people mix it in the same application or worse, but the same class.

I see some pretty terrible things with txtName, NameTextBox, name and textBox1, which are all used in the same form ... yuck.

Where I work, we have a standard document that tells us how to do it, where to do it, and I think that only 20% of people even try to fit and match.

I usually change something if Fxcop yells at me.

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

Capitalization styles

Please note that: For most identifiers, Microsoft.NET recommends UpperCamelCase (aka "Pascal Style"). (it is recommended to use lowerCamelCase for parameters).

Answer 7

I use notation with one small difference.

Now I am working on a project with a rather rich user interface. Therefore, searching with Intellisense for a button called, say, btnGetUsers is very simple.

Everything becomes more complicated when the application can receive users from different places. These are different controls. So I started calling my controls after where they are, and still use Hungarian notation.

As an example: tabSchedAddSchedTxbAdress means that txbAddress is a text field in which the address can be inserted and located on the Add Schedule tab from the planning tab control. This way, I can easily find the controls, and when I just type “btn”, I don’t get several buttons from all over the interface.

Of course, this is only to help yourself. I do not know such a best practice. However, this helps a lot.

Mosu

Answer 8

I call all the user interface elements of TypeDescriptor. Following your example, TextBoxName .

Answer 9

Recently, I have been working with a team that is moving from MFC (6.0 ...). There they will have something like

 CString Name; CEdit ctlName; 

The easiest way to migrate is to use something like

 TextBox ctlName 

This is just a reminder that the variable is a control, not the value of the control.

I think that including this type, as part of the name, is just OLD.

- change - Another advantage is that all controls are grouped together during navigation. If the actual type is used, the ComboBox controls will be quite far from the TextBox controls.

Answer 10

I use c_typeName (note that the type and name are different), for example. c_tbUserEmail for TextBox, into which the user must enter his email address. I find this useful because when there are many controls, they are hard to find in a long intellisense list, so by adding the c_ prefix, I can easily see all the controls in this form.

Answer 11

This madness of Hungarian / VB6 naming needs to be stopped.

If Microsoft really wanted you to write your controls based on their type, then why won't Visual Studio automatically reference “txt” or “btn” when you add the control to your web form or form?

Answer 12

I use Hungarian notation, which makes it easy to find controls on large pages.

Answer 13

For elements that I do not plan to use in my code, I just let the designer handle it for me; if they become something that is used in my code, they change to something meaningful, and this happens to be descriptionType (nameTextBox). This is how the designer creates them if they have enough information (check the menu items - "Exit" becomes exitMenuItem).

Answer 14

My own practice: Type _contextDescriptionType. For example:.

 TextBox _searchValueTextBox 

In any case, the 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 easily access.

Answer 15

You have a guide for names from Microsoft. I will not follow everything, but this is a good starting point

Answer 16

I believe that a naming convention exists to facilitate the development of developer code and helps with manageability. For my understanding, any name that is useful for easy access should be respected.

I saw the number of comments with a different approach, but the best I found in my projects is the control prefix of the 1st three names. There are many reasons for this approach.

• Intellisense combines all the same types.
• The form properties window will also display all the same ordered controls
• In complex forms, you can easily identify that you are dealing with a label or text field (e.g. lblAccounts and txtAccounts).
• A new user can easily handle coding.
• Imagine that I have accountLst, accountlbl, accounttxt, accountgrd, accountChk controls in the same form.

When coding, the developer always knows that he is referring to a text field or label. Where he does not understand what name the other developer used. Therefore, simply by writing "lbl", intellisens will list all the labels where it is, if you used the approach used in # 5, then intellisense will use all the controls using acc. I rarely saw that some loops with a control name start with an “account” or so. This means that it will not help in any rare case.

My bet is to do things that make it easy to understand code for another developer. Because when you grow up in your carrier, you will not always code, someone else will come and take your place.

The choice is yours!

Answer 17

If there is a good separation of problems in the application design, I think there is no need to specify input buttons such as LoginButton, LoginBtn or btnLogin. If the owner of the object is a user interface element, let him call him and if the owner is not a user interface element, then the object is in the wrong place.