What reasons are there to place member functions before member variables or vice/versa?

Given a class, what reasoning is there for either of the two following code styles?

Style A:
class Foo {
    private:
        doWork();

        int bar;
}

Style B:
class Foo {
    private:
        int bar;

        doWork();
}

For me, they are a tie. I like Style A because the member variables feel more fine-grained, and thus would appear past the more general member functions. However, I also like Style B, because the 开发者_C百科member variables seem to determine, in a OOP-style way, what the class is representing.

Are there other things worth considering when choosing between these two styles?

In C++, it is common for those using the class to look at the definition in code, in the header file.

In Java, it is common (but not universal) for those using the class to look at documentation generated from JavaDoc comments. IDEs support style B.

Therefore:

• In C++ I use style A, placing the public interface at the top of the header file.
• In Java, I use style B, placing the data above the methods.

At least you are right, it is only style. And the only reason for style (guides) is to make the code more readable (for a huge audience).

Because style B is more common, more reader will find it more pleasent to read (and can read it faster than style A). And this is the reason why you should use style B (at least for java, c#, php ...)

For what it's worth, I was taught style B and see that style a lot more often than style A. In addition, some languages (specifically, Unreal Script, if you wish to call it a language) enforce style B through compiler checking.

It also makes sense because within the scope of a function you always see variables declared before they are used. It translates well to classes, as typically the functions modify the member variables.

If you look at a UML Class Diagram you will see that the box has three parts: the upper part holds the name of the class, the middle holds the attributes and the bottom holds the methods.

So, this is the way I like to write my code too as it looks much more like my design.

Style A is nice because you can put the variable closer to where it is used instead of having a reader keep referring back to the top.

Typically, people will use style A because class definitions are implicitly private, and virtually no data members are public, whereas quite a few member functions are public. This means that it's simplest to define data members first as their accessibility is much simpler.

class A {
    int bar;
public:
    doWork();
};

Programming in C++ my preferred style is A where the emphasis is on the API the class has. Something like this:

class SomeClass
{
public:
    void foo();
    void bar(int i);

private:
    int m_i;
};

Here the importance is on the interface of this class so the reader can quickly see that first. Due to encapsulation one could even think the private parts are not that important to see first and thus should come last (later).

On the other hand, for e.g. a (low-level) message struct I could argue for the opposite where the members are first to give the reader that information as this could be the most important. Something like this:

struct SomeMessage
{
    uint64_t m_id;
    int32_t  m_number;
    char     m_name[16];

    explicit SomeMessage(uint64_t id);
};

It comes down to how one likes to find information I believe. The only thing I think is important though is to be consistent and not have all conventions mixed.