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()
{
     helpMe();
     helpMeAgain();
}

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.

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.