Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

Some use this convention:

private String event;
public getEvent() { return this.event; } 
public setEvent(String value) { this.event = value; }

private int id; 
... same as above ...

In some projects they define all the fields first, all static fields after (or before), all public/private variables, then the setters, getters, other methods.

Which do you use and why?

share|improve this question

6 Answers 6

I usually keep the private variable with the getter/setter, so the relevant code is all in the same place.

share|improve this answer

I put all the fields, then constructors, then get/sets if any, then methods. That way you can see all of the "meta" object information at the same time. Most of the time, there won't be anything special to see about the get/sets, so I see no point in cluttering up the variable declarations with them.

share|improve this answer
1  
+1. Same here! This kind of sorting usually helps to keep the code neat and tidy. –  ykombinator Dec 8 '10 at 16:24

I use what the people who have gone before me in the code base use. Else I'm with Michael

share|improve this answer
    
+1 For "follow the style in use" –  Orbling Dec 8 '10 at 20:40

I follow the coding standard proposed by FxCop and checked by ReSharper (C#). Nothing like having automated tools to make sure you follow the rules :)

share|improve this answer

I tend to divide my fields into two categories: fields that get initialized right away (i.e. through a constructor, or some initialization method that is expected to be called before other operations) and fields that can be set at any time.

I don't follow any concrete rule, but I think I tend to follow this ordering:

1: Fields that get initialized right away

2: Constructors, particularly ones that initialize the fields from #1

3: Initialization methods that will initialize the fields from #1

4: get/set methods for fields from #1, if applicable.

5: Other fields that can be set at any time, along with associated get/set methods.

6: Methods that utilize fields.

Below is some example code that demonstrates this:

class Example1
{
    // First: Fields with no associated properties,
    // fields with read-only properties,
    // or fields that will be initialized up front (i.e. in a constructor or an initialization method)
    private int _Field1;
    private string _Field2;

    // Second: Constructors
    public Example1(int field1, string field2)
    {
        _Field1 = field1;
        _Field2 = field2;
    }

    public Example1() : this(0, null) { }

    // Third: Methods that initialize fields
    public void InitializeWithExampleData(ExampleDataObject data)
    {
        _Field1 = data.Value1;
        _Field2 = data.Value2;
    }

    // Fourth: Properties for all fields that were previously declared
    public int Field1
    {
        get { return _Field1; }
    }

    public string Field2
    {
        get { return _Field2; }
    }

    // Fifth: Other Fields along with read/write properties
    // i.e. fields that are not initialized by any constructors or methods declared above
    private int _Field3;

    public int Field3
    {
        get { return _Field3; }
        set { _Field3 = value; }
    }

    private string _Field4;

    public string Field4
    {
        get { return _Field4; }
        set { _Field4 = value; }
    }

    // Sixth: Methods that utilize fields
    public int CalculateSomethingBasedOnFieldValues()
    {
        return this.Field1 + this.Field2.Length + this.Field3;
    }
}

struct Example2 // Immutable type example
{
    // First: Fields
    private int _Field1;
    private string _Field2;

    // Second: Constructors (i.e. things that can write to the fields)
    public Example2(int field1, string field2)
    {
        _Field1 = field1;
        _Field2 = field2;
    }

    public Example2(int field1)
    {
        _Field1 = field1;
        _Field2 = null;
    }

    // Third: Properties (i.e. things that can read from the fields)
    public int Field1
    {
        get { return _Field1; }
    }

    public string Field2
    {
        get { return _Field2; }
    }
}

As I mentioned, I'm flexible, but I tend to do this because I think the order of the declarations tends to follow the order of operations that involve the fields, and that makes me happy inside.

First, the fields are declared (i.e. memory is allocated to them). Second, they are set, either through a constructor or an initialization method. Third, they are read, or they are utilized by some other method to perform an operation.

Fields that have both a get and a set method do not clearly follow this flow, since they could be set at any time by a consumer calling the set method, which is why I tend to separate them into a different area.

share|improve this answer

I'll usually define the fields that a property works with and the specific property, then the constructors, then methods. Generally speaking private methods that are related to specific public methods will be grouped together.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.