views:

1882

answers:

14

We are in the process of nutting out the design guidelines we would like to use in our development team and got into a discussion today around how ASP.NET controls should be named. I am talking about our good friends Label, TextBox, Button etc.

We came up with the following three possibilities that we voted on: (Example is a TextBox to enter/display a FirstName)

  1. Add the control type as a postfix to your controls ID: [FirstName_TextBox] or [FirstName_tbx]
  2. Add the control type as a prefix to your controls ID [tbxFirstName]
  3. Set the ID of the control to FirstName and name related fields (like a label for the textbox or a validator) as in option 2 [lblTextBox].

We ended up deciding to use option 2. It's not as verbose as option 1 and I like that it specifies what control it is before the name of the control.

My question is whether Microsoft has released any guidelines for these prefixes and or if you have any comments about our decision.

A: 

Not really sure about any guidelines, i suspect there are, but I always use number 2 as well!

SteveCl
What is number 2?
Andrew Robinson
In his question he listed 3 options, number 2 would be the second.
SteveCl
A: 

these are really just based on your preferences but yes, option 2 as described is less verbose and indicates to you the type of control even before its name is shown.

cruizer
A: 

We also use number 2, however I'm not totally convinced it is a good approach. It is Hungarian notation from the "bad" kind, meaning that the prefixes signal the type (syntax) and not the purpose (semantics). The problem with this is that what starts as a TextBox might later become a DropDown and then a RadioButtonGroup, and you'll have to rename the control each time.

csgero
I see your point and we did talk about using ui or ux as a prefix, which would solve this problem, however IMHO it makes it less useful.
Christian Hagelid
Controls are about the only place I still use "bad" Hungarian notation because I find it has more upside than downside in distinguishing between controls and "real" variables. As far as the name change if you change the control type, I would argue that this is actually a _good_ thing, since the methods and properties of a TextBox and DropDown, for example, can be quite different. If you do change the control type, changing the name is a simple way to find any potential problem areas in your code that assumes the old type.
Jeromy Irvine
Really, how hard is it to rename a control using Find and Replace?
Dining Philanderer
A: 

Almost everyone uses Hungarian-style prefixes (option 2). Semantic naming is less useful because "Firstname" is actually the texbox.Text value, not the textbox itself.

martin
Who is everyone?
Andrew Robinson
+1  A: 

Two reasons why I prefer option 1:

  1. FirstNameTextBox more closely matches my business object.
  2. More usable with IntelliSense.

Having said that I am considering changing to FirstNameCtrl for the reason csgero pointed out about changing control types. So why bother with any postfix or prefix, to reduce/remove the posibility of conflicts with asp/win form properties.

Tim Murphy
Keep the full names. Drop your consideration!
Andrew Robinson
+3  A: 

Not sure about Microsoft official standards, but this is what i've done through out my development career.

I generally abbreviate the control type in front of the the name of what the control does. I keep the abbreviation lower case and the control's name CamelCase.

E.g. A texbox for username becomes tbUserName

Here is a list of standard abbreviations I use:

Abbr     -  Control

btn  -  Button
cb   -  CheckBox
cbl  -  CheckBoxList
dd   -  DropDownList
hl   -  Hyperlink
img  -  Image
ib   -  ImageButton
lbl  -  Label
lbtn     -  LinkButton
lb   -  ListBox
lit  -  Literal
pnl  -  Panel
ph   -  PlaceHolder
rb   -  RadioButton
rbl  -  RadioButtonList
tb   -  Textbox
WebDude
My reason for doing this is that intellisense groups together the like controls so when your looking for the right label all the labels are together. I'd add that all my user controls are prefixed uc so I can clearly see all of them.
Dave Anderson
A: 

I'm not sure of the guidelines regarding ASP.NET, but in the book Framework Design Guidelines from Microsoft, there are several best-practice guidelines about naming of class members. Since ASP.NET Controls in most cases result in a protected field of the appropriate type, I consider these naming guidelines to apply for ASP.NET controls as well. In fact Code Analysis does not differentiate on Control reference fields and other fields.

These guidelines recommend using a naming scheme that implies the logical use rather than a type-descriptive variant. There are several reasons for this. The prefix is implies a type to the developer that might not be correct due to later changes. It adds an extra step in code maintainence. If you change your Button control into a LinkButton control the name also needs to be changed to correct the prefix.

For that reason I would call the control FirstNameEdit etc...

Kimoz
A: 

I tend to go with the control type as a prefix and the name of the control afterwards but I always CamelCase so in your example for different types of controls you might have..

  • TxbFirstName
  • DdFirstName
  • ChbFirstName

For intellisense reasons I also always fully qualify the name of the control so I wouldn't do any of the following...

  • TxbFName
  • TxbClientNo
  • TxbNoOfCpn

But ultimately down to personal preference

Nick Allen - Tungle139
UPDATE: I think it does matter what type of control it is, if I know what control type it is I know exactly which property value to target (Value, Selected, SelectedValue, SelectedItem.Text... etc etc etc) without having to go back into the aspx file if i'm not sure.
Nick Allen - Tungle139
A: 

I've been struggling with this problem too. I used to use the "hungarian style prefix".

Now I take a different approach, I try to see the controls as private fields from my class. I don't pre- of postfix my private fields with their type, so why should I do that to an TextBox?

So what used to be:

var newCustomer = new Customer();
newCustomer.Name = txtName.Value;
newCustomer.Address = txtAddress.Value;
newCustomer.City = txtCity.Value;
newCustomer.HasEnoughMoney = cbHasMoney.Selected;

Becomes:

var newCustomer = new Customer();
newCustomer.Name = name.Value;
newCustomer.Address = address.Value;
newCustomer.City = city.Value;
newCustomer.HasEnoughMoney = hasMoney.Selected;

To be honest, I couldn't care less if the "name" control is a text box or what else, I just want it's value.

And if it's not clear enough if your talking about your control or about another field/variable, I think you should either reconsider the name of that field/variable or the function of you class (meaning it might be a little bit to big?).

Davy Landman
A: 

If you look at it from a code maintainance point of view what would be the best notation to look at after you did the code 2 years ago. Although we try to ensure that forms don't have too many fields on them we all know that this sometimes happens. If we used the Hungarian type notation by prepending the control type I think it would be easier to see where that value is coming from instead of having to figure it out in the event the variable name doesn't make it obvious. If you are using any type of Refactoring tool then changing the name of the control would change the code automatically thereby reducing the change control arguement.

osp70
+1 for suggesting looking at 2 year old code and seeing how it could be improved and made easier to read.
Chad Ruppert
+2  A: 

I find that most of the time I care about what kind of information the control is for rather than what control type is currently being used to capture that data, so I prefer the type of information before the control type, so I can find it in a sorted list in the IDE:

  • AgeRangeDropDownList
  • AgreedToTermsCheckBox
  • FirstNameTextBox
  • LastNameTextBox

VS:

  • chkAgreedToTerms
  • ddlAgeRange
  • txtFirstName
  • txtLastName
Mark Cidade
A: 

I don’t think there’s a right or wrong answer here, whatever you decide, I think the most important aspect is just to be consistent when it actually comes to coding.

Brendan Kowitz
A: 

Microsoft does provide some guidance here.

When you drag a control onto a web form you get something like "TextBox1" automatically. That's the IDE telling you that you should change the "1" part for your specific needs.

In that case, "TextBoxFirstName" seems like the way to go.

Shawn Miller
+4  A: 

The reason Visual Studio adds "TextBox1" when you add it to the page is because Microsoft has no way of knowing how you intend to use it. Naming it "Control1" would be too confusing because it could be any number of controls.

Microsoft provides guidance in general for OO naming conventions, but not specifically for naming UI controls. Since UI controls are ultimately variables used in code, they should follow the same convention as any other variable - no hungarian notation prefix.

The main reasons are...

  • Type of control may change from textbox to listbox, then all associated code will have to be fixed (noted earlier)
  • Your code should be more concerned with the content of the control and less with what type of control it is. When you are concerned with the type of the control, you start to depend on certain functionalities and you break encapsulation - you should be able to easily swap controls without changing much or any code. (Basic OOP principle)
  • It is fairly easy to come up with prefixes for the standard controls, but new controls are being developed every day. You may make your own WebUserControl, or you may purchase a set of third party controls. How will you decide which prefix to use for the custom controls? Instead of focusing on the type of control, your code should be concerned with what information is contained in it.

Examples

  • txtFirstName => firstName or FirstName
  • txtState => state or State
  • cboState => state or State (prime example of changing control types what about lstState or rdoState - they should all have the same name because your code is not concerned about the type of control,rather the state the user selected)
  • ctlBilling => billingAddress or BillingAddress (custom control - with hungarian notation it is not very evident what the control even is, but with a meaningful name I begin to understand the information contained in it. i.e. billingAddress.Street, billingAddress.FullAddress etc.)
+1 and accepted answer for providing the links and the explanation behind Microsoft's guidance. Still not sure we'll move away from the prefix option though, purely because of intellisense.
Christian Hagelid
If you think for a second what intellisense does, you'll find out that stating the type in the variable name is completely redundant in a statically typed language, intellisense is able to provide this information and much more.
John Leidegren