Compartilhar via

Member names and UI controls

  • Artigo

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

  • Anonymous
    July 02, 2007
    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.

  • Anonymous
    July 02, 2007
    I often use suffixes based on the control type myself, but I'm not consistent.

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

  • Anonymous
    July 02, 2007
    The comment has been removed

  • Anonymous
    July 02, 2007
    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.

  • Anonymous
    July 02, 2007
    I use resharper, which emboldens lines on the current class's methods, so picking them out of the intellisense lineout is rather easy.

  • Anonymous
    July 03, 2007
    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="http://www.irritatedvowel.com/programming/standards.aspx">IrritatedVowel</a>

  • Anonymous
    July 03, 2007
    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... http://blogs.msdn.com/rprabhu/archive/2004/05/06/127035.aspx

  • Anonymous
    July 03, 2007
    I follow Steve Smith's pattern for the most part.

  • Anonymous
    July 03, 2007
    >>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.

  • Anonymous
    July 03, 2007
    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.

  • Anonymous
    July 03, 2007
    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.

  • Anonymous
    July 03, 2007
    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.

  • Anonymous
    July 03, 2007
    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).

  • Anonymous
    July 13, 2007
    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. }