Rory Primrose

Yeah, I use #2 as well. The "m_" convention looks really weird to me, but it's nice to have the underscore prefix so that you can type "_" and have intellisense show you a list of all your private fields.

#2 for me.

Was there some issue with #3 in VB.NET case insensitivity?

ditto #2. Why type two characters when one will suffice.  _var immidiatly indicates it is a member and nice to use in properties and method arguments.  e.g. string Name { get {return _name;}} and public Foo(string name) { _name = name; }

#2 all the way dude... m_ is just so vb6, and I'm lazy..

I'm actually starting to come around to #3. This seems to be a common/standard practice:

public class Something
{
   public string details;

   public Something(string details)
   {
       this.details = details;
   }

   public string Details
   {
       get { return details; }
       set { details = value; }
   }
}

There is another standard that says don't name two items differing only by case. Not all CLR languages are case-sensitive like C#. This shouldn't be a problem in the above example because the constructor parameter has a local scope with its naming.

I like the above implementation mainly because the constructor parameter name is the same logical name as the property. This avoids having to come up with another name for the parameter, like detailsValue. The this qualifier removes any doubt about which details variables is being referred to.

In this situation though, I think I would still prefer to use _details for the backing field. Interestingly, since the .Net 1.1 framework, the http://msdn2.microsoft.com/en-us/library/ta31s3bc" target=_new rel=nofollow mce_href="http://msdn2.microsoft.com/en-us/library/ta31s3bc" has been to not prefix field names with anything.

#3 is nice from a appearance and readability perspective, however I found I made too many typeo's by accidentely referencing the property instead of member variable or vice versa. Spot the bug:

class Foo
{
   private int x;

   public int X
   {
      set { X = value; }
   }  
}

I like #2.

But in the good old VB6 days the standard was
m_ module level,
p_ parameter passed in to a function or sub
g_ global variable
Constants where all uppercase

With .Net all those rules change.

I like the prefixed of "_" for all class level fields. But inside a function I use #3.  This way I know the scope of the variable at a glance.

i always use #3 and prefix _all_ access with "this.". the problem with a "_" prefix is that you CAN have local variables named this. at least with a "this." prefix you are SURE that it is a member variable.

#2 definitely.  

I've had to debug other people's applications using #3 and spotting obvious mistakes is very difficult.  Especially letters like oO cC xX zZ wW sS vV where only the size of the first letter differentiates. Yikes.

You all have great points and it is hard to argue against painful experience. I think I like a hybrid.

public class Something
{
  public string _details;

  public Something(string details)
  {
      _details = details;
  }

  public string Details
  {
      get { return _details; }
      set { _details = value; }
  }
}

Brad Abrams (http://blogs.msdn.com/brada/articles/361363.aspx) favours #3

string name = "David";

protected void Page_Load(object sender, EventArgs e)
{
    string name = "Andrew";

    Response.Write(name);
    Response.Write(this.name);      
}

interesting though this will error in VS2005 code analysis??!!