C# and Windows Forms control naming guidelines

Does anyone have any guidelines/best pra开发者_JAVA技巧ctices for naming conventions for Forms and controls (e.g., events, buttons)?

---

I usually use Systems Hungarian notation Example:

btnSubmit: is button

lblAccountNum : variable is a label

---

In WinForms I usually use suffixes, so for example:

submitButton
accountNumberLabel

etc.

But a lot of companies still use a prefix, like anthares said.

---

I don't believe any special rules are needed for forms development; the Microsoft .NET naming guidelines cover it.

I name forms like any other class in the application: MainForm, SaveDialog, etc.

I name controls like any other field within a class: okButton, nameTextBox, etc.

---

I usually prefix the full class name e.g. textBoxName. I find it easier to read than three letter prefixes and it's consistent with the names that are generated by the IDE. I only name controls that are referred to by code. Controls that are databound usually don't need a name.

---

The following example is most of the .net programmer is used

Control: Label
Prefix : lbl
Example: lblFirstName

---

The reason that the prefixes are not the full class names in most of the companies but some abbreviations of the class name are as follows:

1. Most of the naming conventions are approved before Visual Studio 2010.
2. All Visual Studio versions before 2010 have their inteli sense filter with something like "starts with" instead of contains.

That's why a lot of people / architects / leaders decided it will be a better idea to type "txt" and inteli sense will filter all textboxes for you, so then you just type "E" for example and you get txtEmail. If you have the full class name, you will need to type "textBoxE" to get the same result in inteli sense. This adds a lot of overheat when you have complex UI.

Now with Visual Studio 2010 you get a better inteli sense so you can just type "em" and you can easilly see the "textBoxEmail" in the list (along with Email and some other things that contain "em"). Still I seem to prefer to have 2-3 or up ot 4 letters abbreviation that will allow me to filter in inteli sense by control type (specially for UI) than having to type textBox. The reason I prefer it is that even if you are puzzled for a while with some control type (e.g. "rg" for RadGrid) you will need 5 minutes 3-4 times to remember it and start typing without thinking about it. While if you have radGrid everywhere you will need to hit 7 strokes to get to the meaningful one that will filter for you (e.g. "radGridC" in "radGridCustomers").

I do agree that only naming controls that are referenced in the code is usually enough.