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;
}

When guidelines are summarized or adapted from another source, the attribution link should be more noticeable that it is a link.

(Summarized from a blog comment.)