Do you (re)arrange your class methods? Why?

Lots of (open-source) libraries I go through seem to (re)arrange the methods of member classes in a specific manner e.g. such that any class methods that are to be used by other methods within that class are defined first.

For example:

<?php
class Dispatcher
{
    public function isDispatchable()
    {
        $number = rand(0, 200);

        return ($number < 100) ? true : false;
    }

    public function dispatch()
    {
        if ($this->isDispatchable()) {
            // implementation goes here...
        }
    }
}

Here, isDispatchable() is defined before the method that uses it.

I generally just append new methods to the end of the class whether or not the other methods that use it are above or below. Should I be sent north of the wall?

What do you do?

Comments

[Valentin Baca]

Here's what I do, but not incredibly consistently:

1. follow the style of the package your in. Usually consistency is better than splitting hairs over the "right" way"
2. If there's no consistent style established and if a class has only a few private helper functions, I try to keep the private helper methods next to the public methods that use them. Then...
3. If there's no consistent style and there are many private methods or the private methods are used by several, I eventually put all public methods on top and private methods below.
4. If things get too hairy, I just let IntelliJ sort it out.

That's for languages like Java that really don't care what order the methods are defined. In languages like C or Javascript that have to have definitions or have hoisting, it's a little more complicated so I usually just define all helper functions first like you have in your example.

[RevanProdigalKnight]

In some older languages (e.g. C), functions are (or at least were) required to be declared before they can be used, so that became an unofficial (compiler-enforced) convention for a lot of people.

It can also be useful because if you see a function call inside of another function, you know that the definition has to be above the function you saw it in (if there's no other discernable order to function declaration, e.g. alphabetization).

[Nicolas Bousquet]

I try to put methods working on the same subject near to each other. But I tend to put constructors/init methods at the begining of the file, just after fields and constant.

Sometime I like to have the public interface method first and their implementation later on.

But to me, if a class/file has more than a few methods with some significant code, it start to lack readability and I prefer to refactor.

200-300 lines for a file is great. 500 lines is acceptable. 1000+ is usually bad. That counting imports, comments and all.

There obviously exception. Facades for example shall have all the relevant method to help discoverability and keep things clean. But that doesn't mean the implementation has to do more than just redirecting to other classes that do the actual job.

[Adrian B.G.]

There is no absolute truth, except when is forced by the compiler/interpreter.

Make your own rules, based on your project & coworkers. This kind of decisions are planned or made ad-hoc while the project grows.

Usually I saw new code goes to the end of the file. Pro: good for the old devs that know the project, bad: makes no sense for a newcomer.

Based on my preference you should be sent to the North, but so as we :)