Coding Conventions for C#

Collapse
This topic is closed.
X
X
 
  • Time
  • Show
Clear All
new posts
  • Andrea Williams

    Coding Conventions for C#

    Responding to this link in an old thread:

    ml/cpconnetframewo rkdesignguideli nes.asp

    According to that naming convention, a parameter should be be named like
    this "typeName" (ei stringFirstName ). The types that they list add to the
    variable name and the amount of typing to do by quite a lot when compounded
    by the amount of code that goesinto creating an app. Is there anyone still
    using the hungarian convention or a variation of it?

    Even though the hungarian convention is supposedly no longer considered good
    in the Naming Conventions for Microsoft, I'm considering using it just to
    cut down and the amount of typing. Any programmer is going to know what it
    means and it will cut down on the amount of code.

    Maybe there's a good reason for typing out the whole data type word,
    anyone??

    I would also prefer to perfix private members with something. VB used "m_"
    and it looks like c++ did as well, although it may be a little messy... I
    think I like just the underscore only, "_".

    Also, I believer the basic reason that the hungarian notation is out is due
    to the fact that VS.NET is strongly typed. But that only helps you IF you
    are using VS.NET. If you're using some other program, say like Notepad, you
    wouldn't have the benefit of iintellisense and I would think that the
    hungarian notation would still be valuable.

    Any other thoughts?

    I have the task of setting up our company naming and coding conventions and
    I would like extra input before I settle on one specific set of guidlines.

    Thanks in advance,

    Andrea Williams


  • Tony Nassar

    #2
    Re: Coding Conventions for C#

    I like an abbreviated Hungarian notation for .NET controls; it makes using
    the code completion much easier. I used to have C++ that explicitly
    referenced "this," but now I do it all the time in C#, for similar reasons.
    My company's standard prefix for member variables is "m_"; I *don't* like
    that because it requires me to type an extra two characters, incl. that
    inconvenient '_', to get code completion. However,
    using '_' as a prefix is short-sighted; it's NOT CLS-compliant, and in the
    world of C/C++, it's often considered bad style (because of collisions with
    legacy globals).

    On the other hand, strings are so ubiquitous that prefixing every string
    variable with "string" seems silly, to say nothing of "num", "countOf", etc.


    Comment

    • mikeb

      #3
      Re: Coding Conventions for C#

      Andrea Williams wrote:[color=blue]
      > Responding to this link in an old thread:
      > http://msdn.microsoft.com/library/de...us/cpgenref/ht
      > ml/cpconnetframewo rkdesignguideli nes.asp
      >
      > According to that naming convention, a parameter should be be named like
      > this "typeName" (ei stringFirstName ). The types that they list add to the
      > variable name and the amount of typing to do by quite a lot when compounded
      > by the amount of code that goesinto creating an app. Is there anyone still
      > using the hungarian convention or a variation of it?[/color]

      I think you're getting a bit confused on what they're advocating - they
      don't suggest prefixing parameter names with the type of the parameter.
      Note that in the example they give, the typeName parameter is a string
      type, but they didn't call it stringName.

      The guidelines explicitly say:

      =============== =============== =============== ===
      Use names that describe a parameter's meaning rather than names that
      describe a parameter's type. Development tools should provide meaningful
      information about a parameter's type. Therefore, a parameter's name can
      be put to better use by describing meaning. Use type-based parameter
      names sparingly and only where it is appropriate.
      =============== =============== =============== ===
      [color=blue]
      >
      > Even though the hungarian convention is supposedly no longer considered good
      > in the Naming Conventions for Microsoft, I'm considering using it just to
      > cut down and the amount of typing. Any programmer is going to know what it
      > means and it will cut down on the amount of code.
      >
      > Maybe there's a good reason for typing out the whole data type word,
      > anyone??
      >
      > I would also prefer to perfix private members with something. VB used "m_"
      > and it looks like c++ did as well, although it may be a little messy... I
      > think I like just the underscore only, "_".
      >
      > Also, I believer the basic reason that the hungarian notation is out is due
      > to the fact that VS.NET is strongly typed. But that only helps you IF you
      > are using VS.NET. If you're using some other program, say like Notepad, you
      > wouldn't have the benefit of iintellisense and I would think that the
      > hungarian notation would still be valuable.
      >
      > Any other thoughts?
      >
      > I have the task of setting up our company naming and coding conventions and
      > I would like extra input before I settle on one specific set of guidlines.
      >
      > Thanks in advance,
      >
      > Andrea Williams
      >
      >[/color]


      --
      mikeb

      Comment

      • Andrea Williams

        #4
        Re: Coding Conventions for C#

        So if the TYPE in typeName doesn't indicate the data type, what does it
        indicate. The example showed the following:

        [Visual Basic]
        Sub Write(doubleVal ue As Double);
        Sub Write(singleVal ue As Single);
        Sub Write(longValue As Long);
        Sub Write(integerVa lue As Integer);
        Sub Write(shortValu e As Short);
        [C#]
        void Write(double doubleValue);
        void Write(float floatValue);
        void Write(long longValue);
        void Write(int intValue);
        void Write(short shortValue);

        My resource:


        What am I misinterpreting here??

        Andrea
        [color=blue]
        > I think you're getting a bit confused on what they're advocating - they
        > don't suggest prefixing parameter names with the type of the parameter.
        > Note that in the example they give, the typeName parameter is a string
        > type, but they didn't call it stringName.
        >
        > The guidelines explicitly say:
        >
        > =============== =============== =============== ===
        > Use names that describe a parameter's meaning rather than names that
        > describe a parameter's type. Development tools should provide meaningful
        > information about a parameter's type. Therefore, a parameter's name can
        > be put to better use by describing meaning. Use type-based parameter
        > names sparingly and only where it is appropriate.
        > =============== =============== =============== ===[color=green]
        > >[/color]
        >
        > --
        > mikeb[/color]


        Comment

        • Andrea Williams

          #5
          Re: Coding Conventions for C#

          So I'm curious, do they have you use three character prefixes or one
          character on most and three when needed?

          Example:
          string strName;
          string sName;

          So I should be safe if I just add the 'm' for private members, right? No
          legacy issues with that I hope?

          Andrea


          "Tony Nassar" <tnassar@theana lysiscorp.com> wrote in message
          news:%23StEzJ$% 23DHA.3712@tk2m sftngp13.phx.gb l...[color=blue]
          > I like an abbreviated Hungarian notation for .NET controls; it makes using
          > the code completion much easier. I used to have C++ that explicitly
          > referenced "this," but now I do it all the time in C#, for similar[/color]
          reasons.[color=blue]
          > My company's standard prefix for member variables is "m_"; I *don't* like
          > that because it requires me to type an extra two characters, incl. that
          > inconvenient '_', to get code completion. However,
          > using '_' as a prefix is short-sighted; it's NOT CLS-compliant, and in the
          > world of C/C++, it's often considered bad style (because of collisions[/color]
          with[color=blue]
          > legacy globals).
          >
          > On the other hand, strings are so ubiquitous that prefixing every string
          > variable with "string" seems silly, to say nothing of "num", "countOf",[/color]
          etc.[color=blue]
          >
          >[/color]


          Comment

          • mikeb

            #6
            Re: Coding Conventions for C#

            Andrea Williams wrote:
            [color=blue]
            > So if the TYPE in typeName doesn't indicate the data type, what does it
            > indicate. The example showed the following:
            >
            > [Visual Basic]
            > Sub Write(doubleVal ue As Double);
            > Sub Write(singleVal ue As Single);
            > Sub Write(longValue As Long);
            > Sub Write(integerVa lue As Integer);
            > Sub Write(shortValu e As Short);
            > [C#]
            > void Write(double doubleValue);
            > void Write(float floatValue);
            > void Write(long longValue);
            > void Write(int intValue);
            > void Write(short shortValue);
            >
            > My resource:
            > http://msdn.microsoft.com/library/de...econfusion.asp
            >
            > What am I misinterpreting here??[/color]

            I was actually looking at a different part of the naming guidelines (the
            "Parameter Naming Guidelines" page).

            However, if you look closely at the "Avoiding Type Name Confusion" page
            page you pointed out, the section you're citing is their example of what
            *not* to do.

            Right before the box with the example, there's a line that says;

            ------------------------------------------
            Do not create language-specific method names, as in the following example.
            ------------------------------------------


            Later they say that *if* you must include the data type in the parameter
            name, you should use the 'universal' type names instead of the language
            specific variants, since they differ by language sometimes (ie., float
            in C# is Single in VB.NET)

            In the "typeName" parameter example, they name the parameter that way
            because the parameter to the GetType() method specifies the name of the
            type desired. Note again, that the actual type of the "typeName"
            parameter is System.String.
            [color=blue]
            >
            > Andrea
            >
            >[color=green]
            >>I think you're getting a bit confused on what they're advocating - they
            >>don't suggest prefixing parameter names with the type of the parameter.
            >> Note that in the example they give, the typeName parameter is a string
            >>type, but they didn't call it stringName.
            >>
            >>The guidelines explicitly say:
            >>
            >>============= =============== =============== =====
            >>Use names that describe a parameter's meaning rather than names that
            >>describe a parameter's type. Development tools should provide meaningful
            >>information about a parameter's type. Therefore, a parameter's name can
            >>be put to better use by describing meaning. Use type-based parameter
            >>names sparingly and only where it is appropriate.
            >>============= =============== =============== =====
            >>
            >>--
            >>mikeb[/color]
            >
            >
            >[/color]


            --
            mikeb

            Comment

            • Dennis

              #7
              Re: Coding Conventions for C#

              Can I suggest that you look at the following link. It is a combined
              coding standard which we wrote based on the Microsoft .NET Guideline
              and a C++ standard that Philips Medical Systems has been using for
              years.



              Dennis Doomen
              Sioux TSO B.V.

              mikeb <mailbox.google @mailnull.com> wrote in message news:<udT9NlA$D HA.2520@TK2MSFT NGP11.phx.gbl>. ..[color=blue]
              > Andrea Williams wrote:
              >[color=green]
              > > So if the TYPE in typeName doesn't indicate the data type, what does it
              > > indicate. The example showed the following:
              > >
              > > [Visual Basic]
              > > Sub Write(doubleVal ue As Double);
              > > Sub Write(singleVal ue As Single);
              > > Sub Write(longValue As Long);
              > > Sub Write(integerVa lue As Integer);
              > > Sub Write(shortValu e As Short);
              > > [C#]
              > > void Write(double doubleValue);
              > > void Write(float floatValue);
              > > void Write(long longValue);
              > > void Write(int intValue);
              > > void Write(short shortValue);
              > >
              > > My resource:
              > > http://msdn.microsoft.com/library/de...econfusion.asp
              > >
              > > What am I misinterpreting here??[/color]
              >
              > I was actually looking at a different part of the naming guidelines (the
              > "Parameter Naming Guidelines" page).
              >
              > However, if you look closely at the "Avoiding Type Name Confusion" page
              > page you pointed out, the section you're citing is their example of what
              > *not* to do.
              >
              > Right before the box with the example, there's a line that says;
              >
              > ------------------------------------------
              > Do not create language-specific method names, as in the following example.
              > ------------------------------------------
              >
              >
              > Later they say that *if* you must include the data type in the parameter
              > name, you should use the 'universal' type names instead of the language
              > specific variants, since they differ by language sometimes (ie., float
              > in C# is Single in VB.NET)
              >
              > In the "typeName" parameter example, they name the parameter that way
              > because the parameter to the GetType() method specifies the name of the
              > type desired. Note again, that the actual type of the "typeName"
              > parameter is System.String.
              >[color=green]
              > >
              > > Andrea
              > >
              > >[color=darkred]
              > >>I think you're getting a bit confused on what they're advocating - they
              > >>don't suggest prefixing parameter names with the type of the parameter.
              > >> Note that in the example they give, the typeName parameter is a string
              > >>type, but they didn't call it stringName.
              > >>
              > >>The guidelines explicitly say:
              > >>
              > >>============= =============== =============== =====
              > >>Use names that describe a parameter's meaning rather than names that
              > >>describe a parameter's type. Development tools should provide meaningful
              > >>information about a parameter's type. Therefore, a parameter's name can
              > >>be put to better use by describing meaning. Use type-based parameter
              > >>names sparingly and only where it is appropriate.
              > >>============= =============== =============== =====
              > >>
              > >>--
              > >>mikeb[/color]
              > >
              > >
              > >[/color][/color]

              Comment

              Working...