m_ for denoting class level variables

[scottdorman]

From Joe Healy (July 28, 2014 3:04 PM)

m_ for denoting class level variables. Right or wrong? Still pops up occasionally! Hard habit to break for old c++ / mfc coders. And NOT covered in your docs.

From Jonas Stawski (‎July ‎28, ‎2014 3:12 PM)

Depending on the project I simply use _

Example:

private string _name;
public string Name 
{
   get { return _name; }
   set { _name = value; }
}

From Shayne Boyer (July 28, 2014 3:34 PM)

Drop the _ and just lowercase the private.

From Jonas Stawski (‎July 28, ‎2014 3:36 PM)

Yes, I do that as well, hence why I said depending on the project, and by that I mean, depending on the people involved. Sometimes I also make the constructor variable without underscore and the private variables with.

public class Person
{
   private string _name;
   public Person(string name)
   {
        _name = name;
   }
}

From Kevin Schaefer (July 28, 2014 3:40 PM)

Last I saw, privates should still start with _, but not m_.

From: Scott Dorman (July 28, 2014 4:49 PM)

Guidelines right now are culled from the Framework Design Guidelines, which don't explicitly call out using m_ for class level variables. It does mention s_ and g_ for static/global variables. There is also a guideline about not starting any identifier with just an _. I can add something about not using m_ to the guidelines...or someone can file a bug and/or pull-request to add it. :)

From Jim Wooley (July 28, 2014 5:15 PM)

Coming from the VB world I still use underscore to I'd module level fields as distinct from public properties since you can't differentiate only on case in VB (which is prohibited in the CLI guidelines.) It also helps to avoid the common mistake of this:

string foo;
public Bar(string foo)
{
   foo = foo;
}

[scottdorman]

That's my point, Jim. Differentiating only by case wouldn't work for languages like VB, which are case insensitive. The guidelines right now are very generic in nature and are .NET language agnostic. I can easily create more language specific variants.

[thoemmi]

The Framework Design Guideline says explicitly on naming private fields (emphasis mine):

The field-naming guidelines apply to static public and protected fields. Internal and private fields are not covered by guidelines, and public or protected instance fields are not allowed by the member design guidelines.

So no help by Microsoft :wink:

I always prefix my private fields with _:

• easier code in c'tors (no this.param = param, see Jonas' comment above)
• easier to distinguish from local variables

[scottdorman]

@thoemmi: Distinguishing between local variables and class variables shouldn't be an issue. Local variables can't be prefixed with "this". As for "easier code in constructors", I prefer the this.param = param syntax as it's completely unambiguous.