none
C# .NET Naming Conventions RRS feed

  • Question

  • Does anyone know where I can find a list of naming conventions for UI elements.  I found a bunch of places where they have variable, property, method, event handler, formatting style, etc. conventions.  But I am having a hard time finding naming conventions other than the Visual Basic 6.0 Naming Conventions on Microsoft's website.
    Saturday, October 8, 2005 5:12 PM

Answers

  • Hi,

    I dont think there is any official document which lists the 3 letter prefixes for all the new controls in .NET. You can create a standard of your own and as long as you document it and use it consistently in your code it should be fine.

    For further tips on naming conventions - take a look here:
    http://weblogs.asp.net/scottdockendorf/archive/2005/01/26/361020.aspx

    Regards,
    Vikram
    Saturday, October 8, 2005 6:10 PM
    Moderator
  • Probably the biggest reason you can't find what you're looking for is that the standard of prefixing controls/variables with three characters indicating the type (called Hungarian Notation) is not used at Microsoft anymore. Instead, the approach is as you saw described in the documents that were referenced above. For a decent explanation of why this took place, check out the following link:

    http://www.irritatedvowel.com/Programming/Standards.aspx
    Saturday, October 8, 2005 9:34 PM
    Moderator

All replies

  • I've actually already looked at that page, unfortunately, it doesn't give me what I'm looking for.  Maybe I can explain a little better what I need:

    In VB6.0 Microsoft lists prefixes for common control elements:
    For example:
    Textbox [txt] = txtMyTextBox
    Menu [mnu] = mnuFileOpen
    etc.

    I'm looking for a list comparable to that, more updated than VB6.0, and preferably directed to C#.NET.

    Thanks for the link though, it does help for future reference.

    Saturday, October 8, 2005 5:59 PM
  • Hi,

    I dont think there is any official document which lists the 3 letter prefixes for all the new controls in .NET. You can create a standard of your own and as long as you document it and use it consistently in your code it should be fine.

    For further tips on naming conventions - take a look here:
    http://weblogs.asp.net/scottdockendorf/archive/2005/01/26/361020.aspx

    Regards,
    Vikram
    Saturday, October 8, 2005 6:10 PM
    Moderator
  • I was beginning to wonder that, when I could only come up with VB6.0 naming conventions.  Well, I will keep looking but at this point, I will probably work with a mixture of VB6.0 standards and some of my own.  Thanks for your help.
    Saturday, October 8, 2005 7:41 PM
  • Probably the biggest reason you can't find what you're looking for is that the standard of prefixing controls/variables with three characters indicating the type (called Hungarian Notation) is not used at Microsoft anymore. Instead, the approach is as you saw described in the documents that were referenced above. For a decent explanation of why this took place, check out the following link:

    http://www.irritatedvowel.com/Programming/Standards.aspx
    Saturday, October 8, 2005 9:34 PM
    Moderator
  • I use the following naming convention

    For exsample
    TextBox customerCodeTextBox=new TextBox()
    Label customerCodeLabel=new Label()

    You know guy.  Many many control in .net that we cannot convert all to some prefix name.  So I choose this naming....easy and fit any new control

    Sunday, October 9, 2005 2:19 PM
  • Yeah that old VBSUX naming convention actually made programming harder.
    Do you really care what type the control is??? No you care what data the control represents 

    for example, I want to send the customer number that a user has typed into a text box to a function and I have 10 text boxes on the form. . . .

    I had to type:

    "Process(txt" 

    Before Intellisense started to show me what I was looking for, and it would show all the text boxes.  

    where as
    "Process(cus" 
    shows me the controls that are 'oriented' to the task at hand

    Sunday, October 9, 2005 6:46 PM
    Moderator
  • What if you also have a label, a button, a comboBox...named "cus..." that deal with customer data?

    Typically, I know what type of control I'm using for UI IO, so having textboxes grouped can help.

    Now, all that said, I have switched to naming UI controls like any other class-level object:
    txtCustomerNumber becomes "_customerNumber". This leads to some debate as to the naming of business objects. If I also have a class that encapsulates customer numbers, what do I name it? I've toyed with the idea of prefixing UI controls e.g. _uiCustomerNumber, but that is a slippery slope back to hungarian. To date, I have not seen a single convention that solves all problems.
    Sunday, October 9, 2005 9:10 PM
  • I have a couple of generic points to make. I believe that it's much more important to have a convention then it is to have a specific convention. The biggest reason for a convention is to eliminate distracting thought from the development process. A coder shouldn't have to spend an instant figuring out what the name of the text box containing the customer's name is. With a convention, they will just 'know' because they've done similar stuff in the past. So pick a convention, document it, work with it and you'll gain the benefits.

    As for a single convention that solves all problems, they're not actually intended to solve problems. See my comments in the previous paragraph for their purpose ;)

    So while I might disagree with your suggestion that the control type is more important than the data contained by the control (and I do) or that variable names should start with an underscore (which I also do, but case insensitivity makes it a tougher one to hold), ultimately, my opinion doesn't matter. All that matters is the existance of the convention and the strictness to which code is created against that. Which means that FxCop should be part of every developer's toolbox.

    Monday, October 10, 2005 4:49 AM
    Moderator
  • Hi,

    Yes. I agree completely with that, its more important have a convention and to follow it consistently than having a specific convention.

    Regards,
    Vikram
    Monday, October 10, 2005 4:14 PM
    Moderator
  • I usually work something like this:

    class _Description
    {
        object _DescriptionType;
        void _Description(object _descriptiontype)
        {
           object _DESCRIPTIONTYPE;
        }
    }
    Friday, October 14, 2005 8:27 PM
  • I want to have their types as part of the variable name, or I'll easily get confused. ;)

    I tend to use names like:

    Label lblDescription;
    TextBox txtAge;
    Button btnOK;
    ComboBox cboInputType;
    ListBox lstMembers;
    ListView lvwResults;
    MenuItem mnuFileOpen;
    MaskedTextBox mtxtPhone; // prefix as a TextBox "modifier"
    GroupBox grpAddress;
    DateTimePicker dtpCurrent;
    LinkLabel llblAuthor; // prefix as a Label "modifier"
    CheckedListBox clstMovies; // prefix as a ListBox "modifier"
    CheckBox chkShowHidden;
    RadioButton rbtnPause; // prefix as a RadioButton "modifier"
    ... well you get the picture :D

    For other variables, a very simple prefix system...
    I want it to be as little "wordy" as possible, but still not complex like "hungarian" notation.

    int iCount;

    string sName; // I understand "sz" (string, zero-terminated) would be better because this conflicts with short, but I never really use shorts, just ints or longs so I rarely get into that trouble and "s" is very much more used so it's nice to have a short id for that.

    double fValue; // I actually use "f" here, because I never really use the "float" type anyway, and it's more for historical reasons of being used to "f". Maybe bad, but I get across the message it's a floating point value anyway.

    long lFileSize;

    bool bEnabled;

    char chDelimiter; // yes, not "c", no idea why ;)

    unsigned int nCount; // the only unsigned I really tend to use, otherwise I guess I'd go for "ulFileSize".
    Saturday, October 15, 2005 8:47 PM
  • So, what do you do for classes/types like "Stream", "File"? Or when you need to create a class that has at it's beginning the same letter's you're already using? I believe this is one of the reason for the fact that Hungarian notation fell out of favor.
    Saturday, October 15, 2005 9:10 PM
    Moderator
  • As the programming world is rapidly moving away from hungarian notation, it's easy to state that you should not use it, or any type of prefixed notation. Naming textboxes "txtThisAndThat" or strings "strThatAndThis" is unnecessary, since the IDE can give you the type and preferred use of all objects (or "variables" if you like) anytime you want it.

    I've been adapting this behavior for a while now, but now I find myself doing postfixing instead. I name textboxes "thisAndThatTextBox" and strings "thatAndThisString". This isn't much better than doing prefixed notation.

    If you want Intellisense to group your object names by type, prefixing is a pretty good thing. The problem with prefixing is that it's originally designed for C, where there were about a dozen or two of built-in types. That made it easy to set unambiguous prefixes (like n for int, c for char, d for double and so on). Now there are thousands of classes... How do you separate prefixes for classes with similar names, or even classes with identical names but that reside in different namespaces?
    Sunday, October 16, 2005 5:16 PM
  •  Jonas Nordlund wrote:

    int iCount;

    string sName; // I understand "sz" (string, zero-terminated) would be better because this conflicts with short, but I never really use shorts, just ints or longs so I rarely get into that trouble and "s" is very much more used so it's nice to have a short id for that.

    double fValue; // I actually use "f" here, because I never really use the "float" type anyway, and it's more for historical reasons of being used to "f". Maybe bad, but I get across the message it's a floating point value anyway.

    long lFileSize;

    bool bEnabled;

    char chDelimiter; // yes, not "c", no idea why ;)

    unsigned int nCount; // the only unsigned I really tend to use, otherwise I guess I'd go for "ulFileSize".


    I don't agree that sz would be better, since these days strings are actually objects where you have no idea how the actual data is represented internally. Why not just call the sName object "name" instead? It tells you exactly as much as "sName", since you always get the type from Intellisense.

    Using f for prefixing doubles could be a problem too, especially if you plan to let someone else look at your code in the future. I know some people that use f for prefixing booleans (f = "flag"), some people that use s for prefixing floats (since float is actually an alias for the System.Single type), and yet some people that use f for file handles...

    At the company where I work, we're adapting a ubiquitous prefixed notation schema for our legacy Visual C++ 6 code. It's really a pain in the bee-hynde to still use prefixed notation, but the only reason we still do it is the constant failures of Intellisense in VC6.

    For all our C# code we have dropped the concept of prefixed notation. This is because we can now trust the IDE to keep track of our object definitions for us.
    Sunday, October 16, 2005 5:26 PM