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.

8 Comments

  • While I don't like Hungarian notation for variable names, I find it does work very well for control names.

    I guess the difference, is that controls then become nicely grouped together in your intellisense. I know I have a label, but I don't know exactly what I called it. So I can type lbl, and then see all labels and pick the right one.

    Just my experience.

  • I can't believe that an article about naming things well in .Net would degrade into a suggestion to use mungarian (mangled Hungarian) notation.

    The fact that you are putting the GrossPrice into a Label rather than into a Literal is completely irrelevant and should not be reflected in the name of the control.

    JobOptions is the same; it could be a select list, a radio button list or a checkbox list, are you going to rename it each time the visual design changes?


  • Instead of a mangled variant of Systems Hungarian notation, consider Apps Hungarian. I think it is even better to semantically name your controls (using either the full name [first item] or short name [second item] but being consistent across the application):
    chJobOptions
    cJobOptions (it is a control with a finite amount of choices)

    outGrossPrice
    oGrossPrice (it is a control that is only there to display information to the user, not to accept any input)

    inFromDate
    iFromDate (a control that accepts input over some undefined amount of choices, in this case a date)

    bNext
    bNext (a control that, when interacted with, causes an action to occur, could be a linkbutton, a hyperlink,a button, or something else entirely)

    tblCustomerOrders
    tCustomerOrders (a control that displays and/or interacts with a collection of data)

    liCustomerOrder
    lCustomerOrder (a control specifically designed to group the details related to a single customer order)

    --
    This allows you to not need to rename the controls when your visual design changes (as it most certainly will). If your conceptual design model changes then, yes, you should rename variables. It also allows you to get the most out of intellisense, requiring 1 letter to get the entire group of controls that embody the goal you are trying to achieve when coding. Take note that this is *only* for controls and would be detrimental if used everywhere.

  • Thank you. I do also!

  • As long as you don't put control names anywhere within quotes I don't have a preference - just consistency. - for that fact don't put anything in quotes (Control Ids,DB Field names etc.). Asp.net gave us the ability to see errors at compile time vs runtime like classic asp - we should take advantage of that.

  • I completely agree. Control names are the only place I use Hungarian notation and it serves me very well. Consider working in a web page with 20 dropdownlists, 20 textboxes, and 20 labels. Within your code, it's very simple to find the textbox control you want with this.txtFirstName. Many disagree, but for those of you who do, just try it with a complex page or Winform and only for control names.

    I think it really makes a difference when you go back to older code that you haven't worked on for some time. You get right back in the groove.

  • These work for me:

    Label/Literal: displayDepartmentName
    CheckBox/RadioButton/DropDownList: selectDepartmentName
    CheckBox: checkDepartmentName
    Repeater: repeatDepartmentName
    Panel: panelDepartmentName

    I lol'ed @ mungarian notation.

  • I completed agree with AndrewSeven and don't believe the advice in this article to be well founded or good practice.

Comments have been disabled for this content.