Efran Cobisi's Blog

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: