185

I've got a large-ish class (40 or so methods) that is part of a package I will be submitting as course-work. Currently, the methods are pretty jumbled up in terms of utility public/private etc. and I want to order them in a sensible way. Is there a standard way of doing this? E.g. normally fields are listed before methods, the constructor(s) are listed before other methods, and getters/setters last; what about the remaining methods?

double-beep
  • 5,031
  • 17
  • 33
  • 41
fredley
  • 32,953
  • 42
  • 145
  • 236
  • Also note that when _working_ with code like this, most IDE's allow you to see the definition of whatever is underneath the cursor automatically. This mean you do not have to do anything but glance. – Thorbjørn Ravn Andersen Mar 10 '17 at 10:57
  • 1
    If you have 40 methods in a single class - you're doing it wrong – Ben May 03 '18 at 17:53

8 Answers8

153

  1. Class (static) variables: First the public class variables, then the protected, and then the private.

  2. Instance variables: First public, then protected, and then private.

  3. Constructors

  4. Methods: These methods should be grouped by functionality rather than by scope or accessibility. For example, a private class method can be in between two public instance methods. The goal is to make reading and understanding the code easier.

Source: https://www.oracle.com/java/technologies/javase/codeconventions-fileorganization.html

cellepo
  • 4,001
  • 2
  • 38
  • 57
Michael
  • 13,838
  • 18
  • 52
  • 81
150

Some conventions list all the public methods first, and then all the private ones - that means it's easy to separate the API from the implementation, even when there's no interface involved, if you see what I mean.

Another idea is to group related methods together - this makes it easier to spot seams where you could split your existing large class into several smaller, more targeted ones.

Jon Skeet
  • 1,421,763
  • 867
  • 9,128
  • 9,194
  • 1
    +1. I prefer to sort by visibility. Shame Eclipse cannot do this automatically (it will always group all constructors together and all methods together.) – finnw Jan 12 '11 at 11:34
  • 17
    @finnw, file a bug report. Stranger things have been known to be implemented from there. – Thorbjørn Ravn Andersen Jan 12 '11 at 12:36
  • You should never write classes that huge in the first place to ever follow the second option. – Ben May 03 '18 at 17:52
  • 4
    @Ben: My experience is that any "never" will have exceptions. – Jon Skeet May 03 '18 at 22:06
  • 1
    @JonSkeet in a few cases, where ordering conventions are no longer relevant, test classes for example. Not to write bad code is better advise than how to arrange bad code. – Ben May 04 '18 at 10:44
  • 2
    @Ben: I think we'll have to agree to disagree. I've written code where there are very naturally many members, without violating any separation of concerns etc. – Jon Skeet May 04 '18 at 14:38
  • 1
    Agree with Jon Skeet. Just take a look at the Java library collection classes which have a significant number of methods and fields. – shawn1874 Apr 14 '19 at 20:00
47

The more precise link to «Code Conventions»: «Class and Interface Declarations»

Timofey Gorshkov
  • 4,987
  • 6
  • 41
  • 66
  • 12
    +1, afaik - this is the ONLY post that actually answers the question. YES there is a standard order as dictated by Oracle and Sun: 1. public comment, 2. class, 3. internal comment, 4. static data, 5. instance data, 6. ctors, 7. methods, and within each section group logically, not by accessibility. – John Henckel May 21 '13 at 13:51
  • @VadimKirilchuk «Internet Archive» was down… – Timofey Gorshkov Oct 07 '16 at 10:02
  • 1
    http://www.oracle.com/technetwork/java/codeconvtoc-136057.html – Elder Geek Feb 08 '18 at 14:34
  • non-archived working link also in [other Answer](https://stackoverflow.com/a/12427127/1357094) – cellepo Jun 09 '22 at 20:54
  • or in short: https://www.oracle.com/java/technologies/javase/codeconventions-fileorganization.html :) – Timofey Gorshkov Jun 15 '22 at 15:10
18

Not sure if there is universally accepted standard but my own preferences are;

  • constructors first
  • static methods next, if there is a main method, always before other static methods
  • non static methods next, usually in order of the significance of the method followed by any methods that it calls. This means that public methods that call other class methods appear towards the top and private methods that call no other methods usually end up towards the bottom
  • standard methods like toString, equals and hashcode next
  • getters and setters have a special place reserved right at the bottom of the class
Qwerky
  • 18,217
  • 6
  • 44
  • 80
  • I really prefer constructors last because a properly written constructor should do very little other than assign its arguments to properties. – GordonM May 06 '16 at 09:21
  • @GordonM Why do you think so? I would go as far as to argue the reverse is true. You should always think of the cleanest API for your classes. And that is often not the way they are stored in, so I often do quite a bit of processing to relief the caller from this burden – Neuron Apr 28 '18 at 04:31
  • @GordonM I am not talking about side effects. So no changes to lists that were passed or anything alike. Just passing and setting values requires that the Class tells you a lot about it's implementation, which should not be the case – Neuron Apr 30 '18 at 10:07
  • @LonelyNeuron Am not quite sure what you're saying here, but it looks like you're saying the constructor should do a lot of setup work other than assigning its arguments to internal state. This is most definitely wrong, because it means things are happening by "magic". A call to ```new Thing()``` should only result in a new Thing being instantiated. It should not result in database connections being opened, files being written, etc etc. – GordonM Apr 30 '18 at 10:07
  • @LonelyNeuron Having dependencies in a constructor doesn't tell you anything about the class's implementation other than what its dependencies are. This is a good thing, not a bad one. – GordonM Apr 30 '18 at 10:08
  • I like ctor first too. When using dependency injection this seems useful as it puts dependencies at the top -- context info for a class; easing me into what the class is by what it uses. Further, languages are starting to provide this sort of thing in the class declaration which is at the top ... Kotlin does this. – steve Aug 14 '23 at 07:47
14

40 methods in a single class is a bit much.

Would it make sense to move some of the functionality into other - suitably named - classes? Then it is much easier to make sense of.

When you have fewer, it is much easier to list them in a natural reading order. A frequent paradigm is to list things either before or after you need them , in the order you need them.

This usually means that main() goes on top or on bottom.

Thorbjørn Ravn Andersen
  • 73,784
  • 33
  • 194
  • 347
  • 1
    youre so right - this is not an ordering issue – kostja Jan 12 '11 at 11:34
  • 4
    You don't always have a choice, for example if you are implementing an interface with a lot of methods. – finnw Jan 12 '11 at 11:36
  • 5
    This is an Android Activity, so there are lots that simply can't go anywhere else, `onPause()`, `onResume()` etc., as well as all of my `OnClickListener` fields, which, although they are fields, don't look or behave like them so it's sensible to list them separately. – fredley Jan 12 '11 at 11:46
  • @finnw, abstract classes are nice and usable for this purpose. – Thorbjørn Ravn Andersen Jan 12 '11 at 12:35
12

My "convention": static before instance, public before private, constructor before methods, but main method at the bottom (if present).

eljenso
  • 16,789
  • 6
  • 57
  • 63
  • For code that is well factored code this is a good approach. I tend to put consuming code above consumed which leads to public before private. – steve Aug 14 '23 at 07:51
2

Also, eclipse offers the possibility to sort class members for you, if you for some reason mixed them up:

Open your class file, the go to "Source" in the main menu and select "Sort Members".

taken from here: Sorting methods in Eclipse

Community
  • 1
  • 1
Stephan Richter
  • 1,139
  • 11
  • 31
1

Are you using Eclipse? If so I would stick with the default member sort order, because that is likely to be most familiar to whoever reads your code (although it is not my favourite sort order.)

finnw
  • 47,861
  • 24
  • 143
  • 221