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.

Is there a best practice for the order to define getters and setters in? There seems to be two practices:

  • getter/setter pairs
  • first getters, then setters (or the other way around)

To illuminate the difference here is a Java example of getter/setter pairs:

public class Foo {
    private int var1,
    var2,
    var3;

    public int getVar1() {
    return var1;
    }

    public void setVar1(int var1) {
    this.var1 = var1;
    }

    public int getVar2() {
    return var2;
    }

    public void setVar2(int var2) {
    this.var2 = var2;
    }

    public int getVar3() {
    return var3;
    }

    public void setVar3(int var3) {
    this.var3 = var3;
    }
}

And here is a Java example of first getters, then setters:

public class Foo {
    private int var1,
    var2,
    var3;

    public int getVar1() {
    return var1;
    }

    public int getVar2() {
    return var2;
    }

    public int getVar3() {
    return var3;
    }

    public void setVar1(int var1) {
    this.var1 = var1;
    }

    public void setVar2(int var2) {
    this.var2 = var2;
    }

    public void setVar3(int var3) {
    this.var3 = var3;
    }
}

I think the latter type of ordering is clearer both in code and in class diagrams but I do not know if that is enough to rule out the other type of ordering.

share|improve this question

closed as not constructive by Walter, ChrisF Oct 9 '12 at 15:22

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.If this question can be reworded to fit the rules in the help center, please edit the question.

6 Answers 6

up vote 1 down vote accepted

The first way. If it's possible always group together or keep close by related functions that operate on the same members.

If you arrange your code in this way it makes it clearer and easier to refactor, since if one class can be factored out of another that is doing too much, the factorisable piece usually revolves around a specific member variable.

In general it is easier to debug, understand and manipulate code when you can see all on the same page the entire lifecycle of an object/variable. I'd go so far as to say that Code layout based primarily on superficialities like scope and alphabetical order will actually mean you miss opportunities to refactor because you cannot see them.

share|improve this answer
    
Would you like to include any further argument for why functions operating on the same members should be kept together? –  N.N. Oct 9 '12 at 15:08
    
Added some reasons. –  Benedict Oct 9 '12 at 15:44

If you are on a team, do what they usually do. Otherwise just pick the one you like more. On the scale of important design choices this is probably somewhere near "which thumb should I use to hit the space bar?"

share|improve this answer
6  
Agree completely. This comes under the heading of "don't sweat the small stuff", which should be everyone's coding standard rule #0 (It is rule #0 in "C++ Coding Standards" by Herb Sutter and Andre Alexandrescu.) –  David Hammen Oct 9 '12 at 13:27
    
I'm sure people have argued a lot on which thumb they should use to hit the space bar ))) –  superM Oct 9 '12 at 13:27
    
@Michael I'm a right-thumber too. I tried using exclusively my left but it was extremely difficult and my typing slowed to a crawl. –  axblount Oct 9 '12 at 14:25
    
@axblount I'm right handed, but always use my left thumb. Just tried my right and had the same experience you described. I also type "y" with my left hand for some reason. –  KChaloux Oct 9 '12 at 19:17

As far as I know, there's no single convention. The Oracle Java Code Conventions section on file organization doesn't explicitly mention the placement of getters and setters, but it does say:

These methods should be grouped by functionality rather than by scope or accessibility.

This doesn't provide any guidance - I could argue that either placement meets this criteria.

Something to consider is that modern IDEs allow you to have more abstract views of the structure of your files than as the textual code component. This, coupled with powerful searching tools, should make it easy to navigate files and find the appropriate methods within even large files.

As an example, Eclipse provides an Outline view that let's you sort and filter methods and fields in different ways, and navigate right to where they are in files. NetBeans had similar functionality, and I'd suspect that most other IDEs do as well.

The only time this might matter is if you are reading the code outside of your IDE. An example might be using an external code review tool or viewing deltas from your version control system.

The best solution would be to simply be consistent across files in a project. Find a standard, document it, and stick to it.

share|improve this answer

Ever Java IDE can generate getters and setters for you. Just use that functionality and leave the order of those methods like the IDE created it. This is generated code, don't touch it unnecessarily.

share|improve this answer
    
I am aware of this. However, e.g. in Eclipse you can choose between different orderings. –  N.N. Oct 9 '12 at 13:33
    
Right. The default option "Fields in getter/setter pairs" seems more useful, because you can add more fields and generate more accessors later without having to worry which method goes where, just put both at the end. –  user281377 Oct 9 '12 at 13:58

It can also depend on the language. In Java there's no real advantage to either order, but in C#, for example, you have the concept of "properties", which group the getter and setter together, so it kind of enforces that ordering. In a language like C++, where you might want different visibility on getters vs. setters (e.g. private setter, public getter), you'd probably do the opposite, since the visibility modifier is given once for multiple methods, rather than individually for each.

share|improve this answer

Group the getter and setter for a single field together, in pairs.

Grouping all the getters together and all the setters together makes it hard to tell which fields have just getters or just setters.

When I am reading code or looking for specific functionality I envision a class as having fields, with each field having a getter and a setter. It doesn't make sense to me for a class to have a getters group and a setters group, each having fields.

share|improve this answer
    
So, you argument is that getters for a field should be paired with getters for that field because it makes it easier to overview how certain fields in a class are handled? –  N.N. Oct 9 '12 at 15:24
    
That, and the conceptual model of what a class is. Classes should be organized primarily by functionality. When creating a class you might decide that it needs a publicly-visible, mutable field. That is the conceptual "functionality", not the syntactic expression through getter and setter methods. –  M. Dudley Oct 9 '12 at 16:04

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