Tech Off Thread

27 posts

Member Variable Prefixes - what do you use?

Back to Forum: Tech Off
  • User profile image
    phreaks

    I used to prefix my global member variables with m_
    A few years back I switched to just an underscore.

    FXCop doesn't like either, what is the 'standard' way?

  • User profile image
    Sven Groot

    Global member variables? You mean public fields? You should never have those, at all, unless it's a constant. Always use properties.

    I prefix my private fields with an underscore in C# and C++, and with an m in VB.

  • User profile image
    Manip

    Sven Groot wrote:
    Global member variables? You mean public fields? You should never have those, at all, unless it's a constant. Always use properties.


    Why?

  • User profile image
    Sven Groot

    Manip wrote:
    Why?

    Bad OO design.

  • User profile image
    phreaks

    Sven Groot wrote:
    
    Manip wrote: Why?

    Bad OO design.


    Bad Design?
    Then how would you accomplish this ?

    public class SomeConcreteClass: SomeBaseClass
    {

       private String _someNeededConstructorVariable;
       private DateTime _effectiveDate;

       public void SomeConcreteClass(String neededVar, DateTime effectiveDate) : base(AppConfig.ConnectionString)
    {
          this._someNeededConstructorVariable = neededVar;
          this._effectiveDate = effectiveDate
    }

          public void DoSomething() 
          {
             //
          }



    }

  • User profile image
    phreaks

    Sven Groot wrote:
    

    Global member variables? You mean public fields? You should never have those, at all, unless it's a constant. Always use properties.

    I prefix my private fields with an underscore in C# and C++, and with an m in VB.



    I meant private fields. I use an underscore, but FXcop is complaining.

  • User profile image
    Sven Groot

    H4L0PR1CK wrote:
    I meant private fields. I use an underscore, but FXcop is complaining.

    I've never had FxCop say anything about stuff that's private.

  • User profile image
    phreaks

    Sven Groot wrote:
    
    H4L0PR1CK wrote: I meant private fields. I use an underscore, but FXcop is complaining.

    I've never had FxCop say anything about stuff that's private.


    Ya, that was odd.
    I downloaded the latest version and upgraded my project to .NET 2.0 it isn't complaining any longer.

    Weird.

  • User profile image
    W3bbo

    Well for private fields, I alternate between underscore prefixed and hungarian.

    Usually underscore prefixed in C# and hungarian in VB (since VB doesn't like underscore prefices)

    Like so:


    public class Foo {
       
        private string _foo;
       
        public string Foo {
            get { return _foo; }
        }
       
    }

    Public Class Foo
        Private strFoo As String
        Public Property Foo
            Get
                Return strFoo
            End Get
        End Property
    End Class

  • User profile image
    mawcc

    I use an underscore, too. But recently I saw that Brad Abrams posted the internal coding guidelines of Microsoft where it is suggested not use a prefix at all and use "this" for distiction of local and member variables:

    Do not use a prefix for member variables (_, m_, s_, etc.). If you want to distinguish between local and member variables you should use “this.” in C# and “Me.” in VB.NET.

    Anyway, when you work on a team, the guidelines should at least exist and be consistent. I don't think the details are too important.

  • User profile image
    davearkley

    H4L0PR1CK wrote:
    

    I used to prefix my global member variables with m_
    A few years back I switched to just an underscore.

    FXCop doesn't like either, what is the 'standard' way?



    Never saw the point in worrying about it. I would never employ a developer who couldn't work out which vars are local - they are marked private and in class scope - simple enough. And I always turn off the FxCop name rules - again I don't see why camelCase should be 'mandatory'.

  • User profile image
    Manip

    Sven Groot wrote:
    
    Manip wrote: Why?

    Bad OO design.


    I don't see why it is...

  • User profile image
    mawcc

    davearkley wrote:
    
    Never saw the point in worrying about it. I would never employ a developer who couldn't work out which vars are local - they are marked private and in class scope - simple enough.


    In this case I agree with you, but in general it is not a good idea to rely on people "working out" something. Reading code should be made as easy as possible. Read Code Complete and you'll understand.


    davearkley wrote:
    
    And I always turn off the FxCop name rules - again I don't see why camelCase should be 'mandatory'.


    If you're using a different consistent naming scheme it's ok, too. But camelCase is widely used and recommended by the C# language designers.

  • User profile image
    AndyC

    Manip wrote:
    

    I don't see why it is...


    It exposes implementation details, breaking encapsulation.

  • User profile image
    Manip

    AndyC wrote:
    
    Manip wrote: 

    I don't see why it is...


    It exposes implementation details, breaking encapsulation.


    So do properties in exactly the same way! ...

    If I do this:

    {
       MyClass myclass = new MyClass(); 
       myclass.thing = 10; 
       MessageBox.Show(myclass.thing.toString());
    }

    Does the class have a global variable or a property? Does it even matter?

    It is silly and wasteful to over-implement your classes just because "it's better OO" when you could add the property implementation if and when it is needed.

  • User profile image
    Minh

    Manip wrote:
    Sven Groot wrote:
    Manip wrote: Why?

    Bad OO design.


    I don't see why it is...

    An oft-used example is -- if you were to write a component & compile it to a dll. If you were to expose your "properties" as public fields -- then later on need to implement them as real properties get/set 'cuz of validation rules -- or something -- then you would break existing code that access your public fields.

    It's best to implement them all as properties and not be sorry later.

  • User profile image
    Manip

    Minh wrote:
    An oft-used example is -- if you were to write a component & compile it to a dll. If you were to expose your "properties" as public fields -- then later on need to implement them as real properties get/set 'cuz of validation rules -- or something -- then you would break existing code that access your public fields.

    It's best to implement them all as properties and not be sorry later.


    That argument doesn't work... Because if you implemented them as properties and then added validation rules later they would still break... It makes no difference, it just makes your code harder to maintain.

  • User profile image
    dahat

    I try to avoid prefixes and underscores whenever possible, for me it all ends up being camel case.

           public class MyClass
           {

              private string someValue;

     

              public string SomeValue

              {

                 get { return someValue; }

                 set { someValue = value; }

              }

     

              public MyClass(string someValue)

              {

                 this.someValue = someValue;

              }

           }

     

Comments closed

Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation, please create a new thread in our Forums, or Contact Us and let us know.