Member names and UI controls

A follow-on to the previous discussion about member names.

There were a variety of opinions, some of which argued for using no prefix at all.

For those of you who are in the group, I'm interested in how you manage things when you are doing UI work, and having to deal with your 3 member variables being swallowed by the 100 methods already defined in the base class.

Is this an issue for you? If so, how do you deal with it?

Comments (15)

  1. Michael says:

    I don’t use prefixes on fields and don’t have any problems with the members on Control and Form. I usually have an idea of what the thing is called (customerNumberTextbox, etc.) and Intellisense does the rest.

  2. grauenwolf says:

    I often use suffixes based on the control type myself, but I’m not consistent.

  3. Steven Smith says:

    I use suffixes with the type name, like FirstNameLabel, FirstNameTextBox, and then perhaps a string property FirstName.  Works for me.

  4. Jon Skeet says:

    One point to note is that if you write GUIs by hand instead of in the designer – or if, indeed, you use WPF – you don’t end up with nearly as many variables to start with.

    For instance, labels rarely need to be changed after they’ve been set up – so there’s no need for a variable to represent it. It’s in the control collection already, and that’s good enough.

    As for the convention to use – I’ve tried various things, and nothing sits terribly well yet. Using something like firstNameInput and totalDisplay works quite well, as it indicates the overall purpose of the variable rather than being tied to a type – so if I go from a text box to a combo box, for instance, there’s no need to change the variable name.

    I can’t help but feel that somehow a lot of pieces of good practice and convention are abandoned when it comes to GUI work – we’d never use names like string1 in normal code, but many people seem to be happy to keep label1 and button1 as created by the designer, and button1_Click as the event handler name.

    I don’t have enough experience of GUI work to know what really works well, unfortunately – beyond naming, and into things like testability. I like the idea of the Humble Dialog Box ( but I haven’t had enough experience of it to evaluate its issues.

    I’m seriously hoping that WPF’s approach to UI will have a good effect – but it’s too early to tell.


  5. Thomas Eyde says:

    I prefix everything with "ux".

    I think we can blame bad gui practices on our designers: Why do a designer give a bad practice default name like "label1"? Personally, I don’t waste my time on removing something that I never put there, and shouldn’t be there in the first place.

  6. Ariel says:

    I use resharper, which emboldens lines on the current class’s methods, so picking them out of the intellisense lineout is rather easy.

  7. Richard says:

    I use ux as a prefix on UI control variables, and I use a leading underscore on member (field) names.

    In other words, I pretty much follow the coding standards at <a href="">IrritatedVowel</a&gt;

  8. JohnB says:

    In the VS2005 designer you can set the GenerateMember property for controls you don’t reference yourself (i.e. not outside of InitialiseComponent()) to false. Means they won’t cluter up everything…

  9. I follow Steve Smith’s pattern for the most part.

  10. Tom says:

    >>For those of you who are in the group, I’m interested in how you manage things when you are doing UI work, and having to deal with your 3 member variables being swallowed by the 100 methods already defined in the base class.<<

    I don’t find that to be a problem in practice.  I think IntelliSense is pretty good about picking the member names that were used most recently and/or most often, so those tend to "pop" more than the others.

    I’m anti-prefix, because they’re not necessary to avoid name clashes, and because I believe that classes should be kept relatively simple.  If you need prefixes to help you keep straight that something is member, static, or a const, then IMO your class is too complicated and should be refactored.

  11. Tom says:

    Forgot to mention, I also don’t add too many non-control members to form classes anyway.  I usually have a separate worker class that houses the guts of the operation.  The GUI form just has delegates that call into the worker class.

  12. Jamie says:

    I prefer to add "m_" to all member variables, including controls (e.g. an OK button might be called "m_ok"). This means that all member variables are in the same general area in the Intellisense list, making them much easier to find.

    Rather than using the default event handler names ("m_ok_Clicked") I choose something meaningful, like "OnOKClicked". This shows that the method is (a) in response to an event, (b) for the OK button and (c) for a click event.

    Other people find that this may be a bit ugly, but it certainly does make the code easier to understand.

  13. Jamie says:

    I forgot to mention that I set GenerateMember to false for any controls which aren’t required to be accessed at runtime. This means that the class isn’t littered with member variables that you’ll never use.

  14. Miral says:

    I usually prefix with the type of control, eg. listBoxAuthors etc.

    Occasionally I lie about it though, especially when the control is actually a custom control — eg. I’ll still use listBoxAuthors even if that control is actually a UserControl or similar that merely exhibits listbox-like behaviour.

    Now I’m getting into WPF, though, I use quite different names (eg. Authors or AuthorsList), and there’s a lot less of them (since most things happen in the XAML instead).

  15. nikhilkh says:

    I use a prefix witht the name. The prefix represents the type of control encoded. I generally also have properties for the values of the control, so these prefixes help me distinguish the control from the value property.

    For example, a label would be: lblName

    A texbox would be: txtboxName

    I generally represent the value of the label with a property.

    string Name


    get { return txtboxName.Value.Trim(); }

    set { txtboxName.Value = value; } // this might have additional validation needed.


Skip to main content