How to name GUI elements?

Question

Hi,

One thing that constantly causing me headache in programming is when I don't have any naming-convention in a domain where I have to deal with a lot elements. It is clearly what is happening to me when using UI designers such as Windows Forms designer.

Everytime I start a new project I am trying to reinvent a "seem-strong" naming convention but it always fail at some points. For me there is 2 main problems compared to classic code definition for naming GUI elements:

• You have to place a lot of variables (GUI elements) which can all be accessed in the same scope, so you need to have to a strong naming convention to find quickly the right element.
• You often need to access to a specific type of GUI control (ex: TextBox, Label, ...), so the best solution for GUI elements is to name them after their types (Hungarian style notation), which can be sometimes confusing and not helping in finding the right element quickly.

If someone has a documentation describing a good convention or a strong convention he invented for its own project, I would really like to know it!

NB: I did not classified this question under .NET or Windows Forms tags has it seems applicable to a lot of frameworks. If not, let me know.

---

EDIT:

In fact the convention I most use is using a reversed hungarian notation (meaning the type comes first) followed by a path based on the UI elements hierarchy. For example, to easily access to a TextBox which belongs to the "Settings" tab of my program I would call it this way:

this.tb_settingTab_xxx

My problem using this convention is that it is not perfect and sometimes fails when you have a UI element that belongs to another which also belongs to another which also belongs to ...

I am really searching for is the unbreakable and handy naming-convention. I am quitely surprised that Microsoft never gaved any guidelines concerning this. Or am I going wrong? (ie. Mark Rushakoff comment).

Answer 1

Hi,

There are various naming conventions described in this post. The key is to remain consistent throughout the project. I deal with a lot of controls, but find it straightforward to label them based on what they are. Textbox = tbMyControl, Label = lblMyControl. The 'MyControl' bit might be the same if they relate to similar aspects (e.g. tbUsername, lblUsername). However, there's no confusion on what I'm accessing. If you find you're getting confused, then maybe you're trying too many different notations? Keep it simple and logical.

Answer 2

Note: I use the following in code that covers - and sometimes mixes - "raw" Win32, ATL/WTL and MFC, so don't take it literally, only the principle. (Also, be forgiving on the m_)

I use a two-letter-shortcut for standard control types, followed by the name which resembles the functionality of the control (in most cases, Identical / close to the label). The name of related controls needs to match of course - e.g.

CStatic m_stBasePath;
CEdit   m_edBasePath;
CButton m_cbBrowseBasePath;

It's not perfect for all scenarios, but generally I'd say a dialog where this isn't good enough anymore might have to many controls for the user already.

I've written three paragraphs that could be titled "details and defense" - and subsequently deleted them, since there's a very clear essence:

Consistency.

I mostly use the dialog resource itself for orientation, and have strict equivalence between resource ID's and associated members. So the "Base path" - related controls aren#t together in an alphabetic order, but I rarely see this as a problem.

The standard control type already contains very obvious information about functionaltiy of a control - a checkbox to enable / disable a group of features or for a boolean option, an edit or drop down to enter/select a value, a button to open a sub dialog, a static control for the label, etc.

I'm not sure how this style transfers if you transfer it to a platform with much more controls or when you use a lot of custom controls, as my WinForms projects have been comparedly small.