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)
- Add the control type as a postfix to your controls ID: [FirstName
_
TextBox] or [FirstName_
tbx] - Add the control type as a prefix to your controls ID [tbxFirstName]
- 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.
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:
Becomes:
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?).
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.
Two reasons why I prefer option 1:
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.
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.
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...
STANDARD CONTROLS:
btn Button
cb CheckBox
cbl CheckBoxList
ddl DropDownList
fu FileUpload
hdn HiddenField
lnk Hyperlink
img Image
ibtn(btn) ImageButton
lbl Label
lbtn(btn) LinkButton
lb ListBox
lit Literal
mv MultiView
pnl Panel
ph PlaceHolder
rb RadioButton
rbl RadioButtonList
tbl Table
txt TextBox
v View
DATA CONTROLS
dtl DataList
dp DataPager
dtv DetailsView
ets EntityDataSource
fv FormView
gv GridView
lds LinqDataSource
lv - ListView
ods ObjectDataSource
qe QueryExtender
rpt Repeater
smd SiteMapDataSource
sds SqlDataSource
xds XmlDataSource
VALIDATION CONTROLS
cpv CompareValidator
ctv CustomValidator
rv RangeValidator
rev RegularExpressionValidator
rfv RequiredFieldValidator
vs ValidationSummary
VALIDATION CONTROLS:
cpv // CompareValidator
ctv CustomValidator
rv RangeValidator
rev RegularExpressionValidator
rfv RequiredFieldValidator