By Peter Eysermans —

Descriptive names versus abbreviations for UI elements

I have been using abbreviations for UI elements for a long time. I think most developers have and still do. When you declare a button which will give the user the possibility to log on, it will be called: btnLogOn (or something similar). At first I wasn’t really thinking this through and automatically started the name of a dropdownlist with ddl, of a label with lbl etc... One day I was programming in Visual Studio, I was creating a trivial user interface, and I typed something like this:

<label for="txtEmailAddress">
  <asp:Literal runat="server" Text="<%$ Resources: CommonResources, EmailLabel %>"></asp:Literal>
</label>
<input type="text" runat="server" id="txtEmailAddress" /><br />
<label for="txtPassword">
  <asp:Literal runat="server" Text="<%$ Resources: CommonResources, PasswordLabel %>"></asp:Literal>
</label>
<input type="password" runat="server" id="txtPassword" /><br />

Then I went to the code behind file and started adding functionality:

string logOnResult = CustomerServiceBusinessObject.LogOn(txtEmailAddress.Value, txtPassword.Value);

When suddenly it hit me: why was I using these ugly names for UI elements (txtPassword, txtEmailAddress) which mess up my code? Why can't I just name them like every other variable I use? So the code above became:

string logOnResult = CustomerServiceBusinessObject.LogOn(emailAddressTextBox.Value, passwordTextBox.Value);

Of course when you are working on a project with fellow programmers, you have to try to follow the same guidelines and naming conventions in order to get consistent source code. If one programmer uses abbreviations and the other isn’t, the result is even worse then when using abbreviations. So I started up the discussion at work. Because I couldn’t convince all my colleague’s we decided to put it on the Development Guidelines. This is a monthly get together with the team where we discuss interesting tools, new development techniques and other geeky stuff that could help us in your daily job.

While discussing the matter the following advantages/disadvantages of using abbreviations were mentioned:

Advantages

  • You can see in an instant what the type of the class member is
  • If you use intellisense and press Control+Enter, al buttons are alphabetically grouped
  • It’s a Microsoft coding guideline

Disadvantages

  • For UI elements like a button the abbreviation is obvious, btn, but for other elements (DataList, DataGrid, ...) there are variations of abbreviations that are being used. This makes it very hard to keep code consistent and readable
  • Because variables of other types for example Strings or Integers are normal typed, the code gets polluted by UI elements

Eventually we decided to leave abbreviations behind and use descriptive names for UI elements. One small step for men, when giant leap for code readability.

To take it to the next step, you could argue that all UI elements are actually class members. And because I prefix all my class members with an underscore, you could do the same with UI elements. So logOnButton would become _logOnButton. I don’t do it like that – yet – because I’m not convinced that it is the way to go. This could be taking it too far.

What do you think? Do you still use abbreviations for UI elements?