Identifying ASP.NET controls is the first step
Every time I build an ASP.NET web form, I invest a certain
amount of my development effort in giving each control a
meaningful identifier. This practice tends to give back
cleaner code, leading the whole code base more mainteinable.
And, as you probably know, code mainteinability is a key
rule to cut down the total cost of ownership (TCO) of
software projects.
I've seen, however, a worrying
number of ASP.NET developers who simply do not care about
control naming and leave their code full of meaningless
identifiers. So, for example, many tend to name their
controls after the flow they follow inside the page:
HeadLabel, BodyLabel, FooterLabel and so on. Many prefer to
use Visual Studio designer and leave it automatically
generate identifiers for their controls: this way, each
control identifier would be made of a common type prefix,
optionally defined by a
ToolboxData attribute, and an incremental number (ie. Label1, Label2, and so
on). These habits, which could effectively deflate the
effort required to build a demo or a very small project,
would eventually have the opposite effect in greater
projects; trying to find out which of your 100 labels is the
right one is like looking for a needle in a haystack.
As
general code naming rules suggest, a better approach
consists in thinking about what your controls are about and
what they are used for within the hosting page. Given that,
you have a starting point you could use to give your
controls a correct identifier; the string you would
eventually come up with is usually made up of one to
three-four combined words, in pascal case, for example:
TotalAmount, Result, LastInsertedAlert, etc.
Many
developers (me included) then tend to prefix this string
with a small one (usually two to four characters in length),
that should make clear the type of the control at the final
users (yes, you included). This practice, which has its
roots in the
Hungarian code notation, a naming convention created by Microsoft's Charles
Simonyi, actually lead to self-describing control
identifiers. So, following this convention, a label
identifier could be for example lblTotalAmount, where the
"lbl" prefix is there just to tell the reader that it is a
Label control and the rest of the identifier tells her its
purpose. A big improvement over seeing your code full of
Label1, Label2, Labeln, eh?
A nice side effect of this good habit is that, whenever you
need to access a certain type of control inside your code,
you could just type its control prefix (lbl, in my example)
and have Visual Studio Intellisense help you, listing all of
the labels contained within your page or control.
Even
if Microsoft is moving away from the Hungarian code notation
in .NET, I think this convention is still very useful with
this kind of naming issue.
Here is a short list of prefixes I use in order to give an
identifier to my controls:
| Control type | Prefix | Examples of use |
| System.Web.UI.WebControls.Label | lbl | lblAmount, lblGrossPrice |
| System.Web.UI.WebControls.Panel | pnl | pnlDetails, pnlMain |
| System.Web.UI.WebControls.Button | btn | btnConfirm |
| System.Web.UI.WebControls.HyperLink | lnk | lnkAuthorInfo |
| System.Web.UI.WebControls.Placeholder | hld | hldDetails |
| System.Web.UI.WebControls.DataGrid | dg | dgCustomers, dgCustomerOrders |
| System.Web.UI.WebControls.GridView | gv | gvCustomers, gvCustomerOrders |
| System.Web.UI.WebControls.DropDownList | ddl | ddlStates, ddlJobOptions |
| System.Web.UI.WebControls.Repeater | rpt | rptDetails |
| System.Web.UI.WebControls.CheckBox | chk | chkNonSmokingRoom, chkWantsNotification |
| System.Web.UI.WebControls.Table | tbl | tblDetails |
| System.Web.UI.WebControls.Menu | mnu | mnuMain, mnuContext |
| System.Web.UI.WebControls.Wizard | wiz | wizUserRegistration |
Beside naming conventions, however, the most important thing to consider while you are giving your controls an identifier is consistency. Whatever technique you adopt, if you are consistent within your code you will eventually end up with more mainteinable software projects.