Best practice for naming convention of UI controls for referencing in code-behind?

Question

What is the best practice for naming UI controls (textboxes, drop-downs, etc.) on forms and reports for reference in the code-behind pages?

I develop a lot of reports and forms in my office. I have several web applications providing about 80+ "live" reports being generated from various and multiple data sources (Access, SQL, Oracle). These reports are considered "live" because they accept user set paramaters from a form, then query the database to produce a report based on the current information available.

So, the process starts with obtaining the values set by the user, passing those to the database query, receiving the dataset, and finally assigning the dataset to the report. In some cases, additional fields displayed on the report need to be calculated from the dataset before the report can be generated. This requires referencing the output controls on the report to assign the calculated value.

While I don't really care to use prefixes in my code for variables or member fields, I do use them to identify the UI controls. For example, txtFirstName to reference the report control to assign the data from the FirstName field in the dataset to the display control on the report. Is there a better practice for naming/referencing UI controls on forms and reports?

Answer 1

Your answers here will be very subjective. Different tastes and programming backgrounds will give you different preferences.

Perhaps what will be most important to you in the long run is consistency among all of your projects, so that regardless of who developed the code you will be able to understand it when reading.

We outsource a lot, so make certain to communicate our naming conventions to all of our project managers.

Here are some links to naming conventions:

http://www.irritatedvowel.net/Programming/Standards.aspx

http://msdn.microsoft.com/en-us/library/xzf533w0(VS.71).aspx

http://www.visualize.uk.com/resources/asp-net-standards.asp

Answer 2

I do similarly to you. When you have tons of controls it all becomes messy, so I prefix each name with the capitals of the control class.

For example:

TextBox -> tbName

DataGrid -> dgName

Panel -> pName

This makes it clear how to handle new controls (i.e. how to derive the prefix)

Answer 3

The main product I work on at work uses the txt_ pnl_ etc prefixes. This does work, though it is a bit of a pain at times when switching something that just hides/shows controls from say, a tr to a panel because you have to rename it.

What I've started doing in new projects, is naming my UI controls with a ui prefix; for example, uiName. Since I am strongly opposed to anti-hungarian notation, and strive for self-documenting code, this convention works well. In fact, if anything, it is real hungarian notation (ui being the prefix meaning user interface control).

Answer 4

I've always felt that the only real reason for the prefixes was so you could have things like txtFirstName and lblFirstName on the same form/page. Since, the vast majority of the time, I'm really only working with the actual field control itself, I skip the prefix for that, and only use the prefixes for associated controls. For instance, lblMonth & Month, skipping the cbo prefix.

It saves typing, and it will generally be obvious what sort of control you're using in such forms. More complex controls will get the full prefix treatment.

Answer 5

I still use Hungarian Notation for Controls but no longer for variables.

btn Button
cbo ComboBox
chk CheckBox
clb CheckedListBox
grp GroupBox
iml ImageList
lbl Label
lnk Hyperlink
mnu Menu
pbr ProgressBar
pic Picture
pnl Panel
rtb RichTextBox
tmr Timer
tvw TreeView
txt TextBox

Answer 6

For GUI controls, I suffix the variable name with the control name:

• firstNameTextBox
• lastNameTextBox
• submitButton

This makes the relationship obvious between for example _firstName and firstNameTextBox.Text, and no one has to remember what the hungarian notation equivalent is. I would always choose clarity over brevity in naming variables.