I've noticed that a coworker and I have opposite practices regarding the ordering of methods in our Java classes. One of us begins a class with its major public methods, and then put all of the private helpers afterwards. The other one of us makes sure that public methods are at the very end.

Clearly, this is just a style issue and there is no right answer. However, before we decide that this matter is just another Yooks vs Zooks fight and just pick one or the other arbitrarily, I was wondering if perhaps there was a standard Java style guide recommendation or some practical reason why one approach is better than the other.

  • 13
    It doesn't matter. Flip a coin. Pick one. Stick with it. – user40980 Feb 8 '13 at 19:05
  • possible duplicate of Helper Methods Placement – Kilian Foth Sep 16 '14 at 8:22
  • 1
    @KilianFoth - This question was asked 3 months earlier and has more answers. Wouldn't that make the question in question a duplicate of this question? – Brandon Yarbrough Sep 16 '14 at 8:33

While it does come down to preference normally, you should certainly try to adhere to a common standard within your organization. So whatever you decide, pick a standard and universally adopt it.

As for which to choose, if you were to follow the suggestions as offered in Clean Code, you would be able to read down the file from top to bottom like a newspaper article, which would naturally suggest that helper methods appear after the methods they are helping. This would lead to maximum readability of the code structure. So if you were to have

public void doSomething()

Your file would be structured as

public void doSomething() { }
private void helpMe() { }
private void helpMeAgain() { }

Another side effect of this is that you discover your helpers have their own helpers, and it helps you figure out what you really have is another class living within your file, and you can cleanly refactor to extract it to its own class since those methods are already grouped together in order. But that's a secondary benefit.

  • 1
    Glad you said this or else I would have. I asked Bob Martin himself how he orders things if 2 methods each use a 3rd method. In that case he puts the 3rd below the other two. – Daniel Kaplan Feb 8 '13 at 23:43
  • 3
    Your example doesn't show it, but this leads to public methods mixed in among the private methods. I use this technique, but often then I feel torn and want to boost all the public methods to the top, because there is also much to be said for reading the public interface easily. – Sean Feb 9 '13 at 13:09
  • 1
    @Sean, well, I would typically try to limit either the public API of my class, or leave it as a facade if appropriate but then shove the implementation helpers down into collaborators. Test, refactor, extract, repeat. But it of course depends on how far you want to go. I prefer my classes small. – Anthony Pegram Feb 10 '13 at 4:09

Public methods are the interface of the class. Someone interested in using your class will only care about the interface. From the perspective of a class user, it would be useful to have the public methods first to reduce scrolling.


In C and C++, helper methods are often put first because then you don't need a declaration. A lot of people carried that habit over into other languages where it doesn't matter.

I prefer the public methods on top because usually when I open a file I'm looking for its public interface. I don't want to have to scroll past all the implementation details. It also happens to be the most popular style I've seen, so there's that to be said for convention.


I like order of methods in a class to be based on readability and context, not visibility.

i.e. an 'open' method probably belongs before a 'close'. If two public methods 'a' and 'b' call a private 'c', and they're the only ones calling it - then I like 'c' to be next to them.

I don't think a convention of method ordering based on visibility is a good thing.


I tend to prefer seing my classes where members are listed in order of importance/visibility (here by importance I mean that have direct impact on the public interface).

Thus private functions have a tendency to be pushed down.

There are exceptions to this where I will also tend to group similar functionnalities together so it is still possible to find small private functions intermingled with the public stuff.

This is, as you said, a matter of taste.

However when working on code that is not mine I will try nd follow whatever conventions that is used in the project.

One nice way I found to keep track of this is to (assuming here you work with Eclipse) create a code formatting configuration and export it with the project source and commit it to source control. That way the latest and greatest in code convention for the project is a mere few clicks away to setup and making a habbit of CTRL-SHIFT-F jufore you commit will prevent a lot of arguments.

Added bonus of using automatic formatters is that you can do things in whatever convention that makes you happy and just format the code before commit. YMMV depending on said convention and formatting tool.

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