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 public labels so that the operations can be kept separate from the constructors and so on? What issues should I take into account when making this decision?

Answer 1

I put the public interface first, but I didn't always do this. I used to do things backwards to this, with private, then protected, then public. Looking back, it didn't make a lot of sense.

As a developer of a class, you'll likely be well acquainted with its "innards" but users of the class don't much care, or at least they shouldn't. They're mostly interested in what the class can do for them, right?

So I put the public first, and organize it typically by function/utility. I don't want them to have to wade through my interface to find all the methods related to X, I want them to see all that stuff together in an organized manner.

I never use multiple public/protected/private sections - too confusing to follow in my opinion.

Answer 2

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 3

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 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

As always, write your code for humans first. Consider the person who will be using your class and place the most important members/enums/typedefs/whatever to them at the top.

Usually this means that public members are at the top since that's what most consumers of your class are most interested in. Protected comes next followed by privates. Usually.

There are some exceptions.

Occasionally initialisation order is important and sometimes a private will need to be declared before a public. Sometimes it's more important for a class to be inherited and extended in which case the protected members may be placed higher up. And when hacking unit tests onto legacy code sometimes it's just easier to expose public methods - if I have to commit this near-sin I'll place these at the bottom of the class definition.

But they're relatively rare situations.

I find that most of the time "public, protected, private" is the most useful to consumers of your class. It's a decent basic rule to stick by.

But it's less about ordering by access and more about ordering by interest to the consumer.

Answer 6

I usually define first the interface (to be read), that is public, then protected, then private stuff. Now, in many cases I go a step forward and (if I can handle it) use the PIMPL pattern, fully hiding all the private stuff from the interface of the real class.

class Example1 {
public:
   void publicOperation();
private:
   void privateOperation1_();
   void privateOperation2_();

   Type1 data1_;
   Type2 data2_;
};
// example 2 header:
class Example2 {
   class Impl;
public:
   void publicOperation();
private:
   std::auto_ptr<Example2Impl> impl_;
};
// example2 cpp:
class Example2::Impl
{
public:
   void privateOperation1();
   void privateOperation2();
private: // or public if Example2 needs access, or private + friendship:
   Type1 data1_;
   Type2 data2_;
};

You can notice that I postfix private (and also protected) members with an underscore. The PIMPL version has an internal class for which the outside world does not even see the operations. This keeps the class interface completely clean: only real interface is exposed. No need to argue about order.

There is an associated cost during the class construction as a dynamically allocated object must be built. Also this works really well for classes that are not meant to be extended, but has some short comings with hierarchies. Protected methods must be part of the external class, so you cannot really push them into the internal class.

Answer 7

I tend to follow the POCO C++ Coding Style Guide.

Answer 8

In our project, we don't order the members according to access, but by usage. And by that I mean, we order the members as they are used. If a public member uses a private member in the same class, that private member is usually located in front of the public member somewhere, as in the following (simplistic) example:

class Foo
{
private:
  int bar;

public:
  int GetBar() const
  {
    return bar;
  }
};

Here, the member bar is placed before the member GetBar() because the former is used by the latter. This can result in multiple access sections, as in the following example:

class Foo
{
public:
  typedef int bar_type;

private:
  bar_type bar;

public:
  bar_type GetBar() const
  {
    return bar;
  }
};

The bar_type member is used by the bar member, see?

Why is this? I dunno, it seemed more natural that if you encounter a member somewhere in the implementation and you need more details about that (and IntelliSense is screwed up again) that you can find it somewhere above from where you're working.

Answer 9

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 10

In practice, it rarely matters. It's primarily a matter of personal preference.

It's very popular to put public methods first, ostensibly so that users of the class will be able to find them more easily. But headers should never be your primary source of documentation, so basing "best practices" around the idea that users will be looking at your headers seems to miss the mark for me.

It's more likely for people to be in your headers if they're modifying the class, in which case they should care about the private interface.

Whichever you choose, make your headers clean and easy to read. Being able to easily find whatever info I happen to be looking for, whether I'm a user of the class or a maintainer of the class, is the most important thing.

Answer 11

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 12

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.

Answer 13

Note that (depending on your compiler and dynamic linker), you can retain compatibility with previous versions of a shared library by only adding to the end of the class (i.e. to the end of the interface), and not removing or changing anything else. (This is true for G++ and libtool, and the three part versioning scheme for GNU/Linux shared libraries reflects this.)

There's also the idea that you should order members of the class to avoid wasted space due to memory alignment; one strategy is to order members from smallest to largest size. I've never done this either in C++ or C though.

Answer 14

Overall, your public interface should come before anything, because that's the main/only thing that users of your classes should be interested in. (Of course, in reality that doesn't always hold, but it's a good start.)

Within that, member types and constants are best first, followed by construction operators, operations, and then member variables.

Answer 15

binary compatibility

There are a few concrete reasons for the ordering of class members. These have to do with binary compatibility.

Binary compatibility mainly affects changes to system DLLs and device drivers. If you're not interested in these, ignore this answer.

Public members must go before private members. This is so you can mix and change private members without affecting the location of public data.

New public members must go last. This again avoids affecting the position of existing public members.

The same ordering applies to vtable members.

Apart from this there's no reason to not to follow your own/your colleagues' preferences.

Answer 16

Depends entirely on your preference. There is no "the right way".

When doing C++ in my own pet projects I personally keep convention that I put access modifier before each member or method declaration.