How should I order the members of a C++ class?

Question

Is it better to have all the private members, then all the protected ones, then all the public ones? Or the reverse? Or should there be multiple private, protected and pub

Answer 1

Google favors this order: "Typedefs and Enums, Constants, Constructors, Destructor, Methods, including static methods, Data Members, including static data members."

Matthew Wilson (Safari subscription required) recommends the following order: "Construction, Operations, Attributes, Iteration, State, Implementation, Members, and my favorite, Not to be implemented."

They offer good reasons, and this kind of approach seems to be fairly standard, but whatever you do, be consistent about it.

Answer 2

i think it's all about readability.

Some people like to group them in a fixed order, so that whenever you open a class declaration, you quickly know where to look for e.g. the public data members.

In general, I feel that the most important things should come first. For 99.6% of all classes, roughly, that means the public methods, and especially the constructor. Then comes public data members, if any (remember: encapsulation is a good idea), followed by any protected and/or private methods and data members.

This is stuff that might be covered by the coding standards of large projects, it can be a good idea to check.

Answer 3

Put the private fields first.

With modern IDEs, people don't read the class to figure out what it's public interface is.

They just use intellisence (or a class browser) for that.

If someone is reading through the class definition, it's usually because they want to understand how it works.

In that case, knowing the fields helps the most. It tells you what the parts of the object are.

Answer 4

It's my opinion, and I would wager a guess that most people would agree, that public methods should go first. One of the core principles of OO is that you shouldn't have to care about implementation. Just looking at the public methods should tell you everything you need to know to use the class.

Answer 5

Coding style is a source for surprisingly heated conversation, with that in mind I risk providing a different opinion:

Code should be written so it is most readable for humans. I complete agree with this statement that was given here several times.

The deviation is which roll are we taking about.

To help the user of the class understand how to use it, one should write and maintain proper documentation. A user should never be needing to read the source code to be able to use the class. If this is done (either manually or using in-source documentation tools) then the order in which public and private class members are defined in the source does not matter for the user.

However, for someone who needs to understand the code, during code review, pull request, or maintenance, the order matters a great deal - the rule is simple:

items should be defined before they are used

This is neither a compiler rule not is it a strictly public v.s. private rule, but common sense - human readability rule. We read code sequentially, and if we need "juggle" back and forth every time we see a class member used, but don't know its type for example, it adversely affects the readability of the code.

Making a division strictly on private v.s. public violates this rule because private class members will appear after they have been used in any public method.

Answer 6

It is really helpful to the folks that will use your class to list the public interface first. It's the part they care about and can use. Protected and private can follow along after.

Within the public interface, it's convenient to group constructors, property accessors and mutators, and operators in distinct groups.