Question

I’ve seen (and used) on various projects this layout, with a group of fields followed by a group of properties:

private int MyIntField; private string MyStringField;  public int MyInt {      get { return MyIntField; }     set { MyIntField = value; } }     public string MyString {      get { return MyStringField; }     set { MyStringField = value; } } 

And I’ve also encountered this layout with fields next to their property:

private int MyIntField; public int MyInt {      get { return MyIntField; }     set { MyIntField = value; } }      private string MyStringField; public string MyString {      get { return MyStringField; }     set { MyStringField = value; } } 

Is there a reason to consider one better than the other? I think most coding standards recommend Option #1, but sometimes it’s handy having the field next to the property that operates on it.

Note: I’m assuming non-trivial properties that can’t use auto-implemented properties.

Answer 1

I think it is whatever the team feels comfortable with. Settle on a standard for the project/company/language and stick to it. I prefer the private variables all together, the methods/interfaces together, the private members….I think you get the point.