views:

101

answers:

4

First of all, I don't want to start a coding styles war, so please only reply if you are answering the question.

I've encountered a couple of people who put their fields at the top of the class. Could anyone who does this explain the rationale behind it?

Many thanks

+8  A: 

I like to group fields at the top of a class only for code organizational purposes. I find it easier to find what I'm looking for more quickly than if fields were spread out amongst the class.

I also typically group other members up by type and also have an internal sort by access modifier.

public class MyClass
{
    // Fields

    // Constructors

    // Properties

    // Methods
}
Wallace Breza
As good a reason as any...
Noldorin
I agree, I find it easier to have the private fields defined in a #region at the top of the page
Simon Hazelton
NO REGIONS! aaaaargh! If you use a region, Jeff Atwood will come round to your house!
Mitch Wheat
I didn't realize I was writing code for Jeff Atwood.
Matthew Whited
I too group my members, although in a different order (Constructors, Methods, Properties then Fields) but, like you, I also subgroup them by access modifier. What I meant to ask was why put them at the top of the class instead of the bottom?
The reason I put them at the top is to give me a quick snapshot regarding the type of state information this given class is responsible for. Even though automatic properties have eliminated many simple fields, i still find myself writing may properties with backing fields by hand.
Wallace Breza
Another vote for state information. Thank you.
+1  A: 

One rationale (at least before auto-properties came into existance) was to group all the state information at the top of the class because it goes a long way towards summarizing what the methods that follow will accomplish.

Kirk Woll
+1  A: 

I put mine at the top of the class, because it causes the properties to cluster together, without the fields in between breaking them up.

But it's largely a matter of preference. Intellisense insures that you always know what an identifier does, and "Go to definition" insures that it doesn't really matter where you put the fields.

Robert Harvey
I agree that it doesn't really matter, it is simply a matter of preference. The problem is when you have people working together who have very different preferences. To me, it's a pain having fields at the top (I put them at the bottom) and couldn't understand why people do. To be honest, I'm still not entirely clear why.
@stevenboy: That's what coding standards and conventions are for, to enforce a degree of uniformity within the code base. The correct standard is the one a given shop uses. When people put the fields at the top (rather than the bottom), they do it because it is logically consistent; fields should be defined before they are used.
Robert Harvey
@Robert Harvey "they do it because it is logically consistent; fields should be defined before they are used": That's a matter of opinion. If it were true, then the class wouldn't compile if you placed fields at the bottom. Anyway, I've now got a clear insight into why people put fields at the top. Thank you.
+1  A: 

If I'm not using Auto Properties I like to keep the backing store next to the property. I like private state fields, static values, and constants, next constructors, then properties, followed by instance methods and then static methods. If I have nested classes those either go to the top of the class if they are used by the entire class or right before the group of methods they are used with.

public class MyClass 
{
    public class MyNestedClass 
    {
    }

    // constants
    // private state fields
    // private static fields

    // constructors

    // properties
    // static properties

    // methods
    // static methods

    // finalizer if required
}
Matthew Whited
That's interesting and completely different to how I order my members.