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

Answer 1

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

Answer 2

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 3

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 4

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 5

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 6

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.