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?

Mcafee

Answer 1

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

Mullite

I like your use of "ui" to prefix the control--for one it is standardized and not implementation specific. Typically only a single incarnation of data field occurs on a form or report (e.g., a textbox containing the value of a FirstName in the detail section of the report is likely to occur once). – Mcafee

Answer 2

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.

Susan

Answer 3

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

Dehnel

Please note, this is "systems hungarian" (or "anti-hungarian"), not true hungarian notation. Hungarian uses the functional type, not the language type. Google for both terms and you'll find the story of why there are two interpretations. – Mullite

Answer 4

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

Seabrooke

Answer 5

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)

Cuthbert

What about when you have a Picture object - "pName" as well? A single letter surely can't capture everything. That's why I prefer a minimum of 3 to easily differentiate. – Epifocal

You misunderstand me. Assume there is a texbox for an email, it would be called "tbEmail", so yeah there's the possibility of having overlaps but it's really minimal. The point is not that of using hungarian notation, but to easily differentiate between say: tbEmail and lEmail (where the second is a label associated with the textbox) – Cuthbert

Answer 6

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.

Microstructure

Answer 7

2-char prefixes for iOS UI components I prefer:

bt_ : UIButton
lb_ : UILabel
tx_ : UITextField
tv_ : UITextView
vw_ : UIView
im_ : UIImageView
sc_ : UIScrollView
tb_ : UITableView
cl_ : UICollectionView
st_ : UIStackView
pk_ : UIPickerView
pr_ : UIProgressView
ai_ : UIActivityIndicatorView
wb_ : UIWebView / WKWebView
mp_ : MKMapView
gr_ : UIGestureRecognizer
sw_ : UISwitch
sl_ : UISlider
sp_ : UIStepper
sg_ : UISegmentedControl
pg_ : UIPageControl
dp_ : UIDatePicker

Ronna