Naming convention for controls


Question

Microsoft has naming guidelines on their website (here). Also I have the Framework Design Guidelines book.

What I could not find was a guideline about naming controls.

For example, a button, when dropped to a form, gets the typename + number, camel-cased as default name, such as "button1".

This is what I do: I delete the number and add a meaningful description after. For example "buttonDelete" or "buttonSave".

This way you do not have to maintain a big list of controls and their abbreviated names in a guideline somewhere.

Do you agree?

1
34
3/22/2017 6:11:32 PM

Accepted Answer

I don't have a convention as such, but I do try to be very broad with the 'type' portion of the name. e.g. Button, Link Button, Image Button tend to be named 'somethingButton'. Combo boxes, radio button lists all end up as 'somethingSelector'. TextBoxes and Calendars are 'somethingInput'. That way I get a rough idea of what sort of control it is without the name being tied to the actual implementation. If I decide to replace an option button group with a dropdown then no need to rename!

20
3/13/2009 1:53:25 PM

Caveat: The following is more directed at WinForm/WPF development. Patrick Peters rightly pointed out that there are bandwidth/performance issues at play when dealing with ASP.NET controls.

There isn't really a standard here, and I believe that this is because its one of the most arbitrary naming scenarios. In most cases, controls are private to the class, and only used lightly in event handlers.

Like other answerers, I too used to spend a non-trivial amount of time "fixing" control names. I would do things like "btnSave", "tbxName" (tbx for TextBox), etc. However, when explaining my scheme to someone else, I realized how arbitrary that was. Is "cbx" a ComboBox or a Checkbox?

This led me to re-examine what the designer does automatically and realize that I can clearly, consistently, and quickly name controls if I let the designer do the work. Its actually very similar to the suggestion of the question poster:

I replace the control number with the semantics of the control. Thus "button1" (the designer default) will be "buttonSave", and "listBox3" will become "listBoxWidgets". If there will only be one control of that type, I just remove the number: "errorProvider1" becomes "errorProvider".

So how is this better?

  • Meticulously "fixing" variable names is a waste of time if its an internal variable
  • Your naming scheme is likely to be ambiguous if it shortens a whole bunch of stuff (CheckBox versus ComboBox)
  • The designer gives a good, consistent starting point that is easy (and quick) to specialize
  • The length of the variable name is irrelevant when you use Intellisense
  • Control names group nicely and intuitively (in Intellisense) when prefaced by their type. When you have 15 TextBoxes on your Form, you just first remember you want a TextBox , type "textBox", and then pick the name from the list.
  • Anyone unfamiliar with your "scheme" can see it immediately and adopt it quicker than anything else.
  • It is VERY fast to provide useful control names...very little keyboard/mouse jockeying to do this...so high productivity with intuitive results. What is not to like?

PS. This is tending towards a Bikeshed question, but as I can paint a bikeshed, I went ahead and joined the discussion. ;)


Licensed under: CC-BY-SA with attribution
Not affiliated with: Stack Overflow
Icon