Is it confusing to omit the “private” keyword from

Question

I recently removed a private specified from a class definition because it was at the top, immediately after the class keyword:

class MyClass
{
private:
    int someVariable;
// ...

I thought that it was redundant.

A coworker disagreed with this, saying that it effectively "hid" the private nature of the data.

Most of our legacy code explicitly states the access specifiers, and usually intermingles them inconsistently throughout the definition. Our classes also tend to be very large.

I'm trying to make my newer classes small enough so that my class definitions are similar to:

class MyClass
{
    // 3-4 lines of private variables
protected:
    //  3-4 lines of protected functions
public:
    //  public interface
}

which would allow omission of the redundant access specifier while (hopefully) keeping the private members close enough to the struct/class keyword for reference.

Am I sacrificing readability for brevity, or are the struct/class keywords sufficient?

Answer 1

Personally, I think it is much more clear with the private keyword included and I would keep it. Just to make sure it is private and everyone else knows it as well.

But I assume this is of personal taste and different for everyone.

Answer 2

While incorrect — strictly speaking — your coworker has a point; an experienced C++ programmer doesn't need the default access spoon fed to them, but a less experienced programmer might.

More to the point: most code I've seen and worked with puts the public stuff first, which renders the question moot.

Answer 3

Technically, "private" at the beginning of a class or "public" at the beginning of a struct is redundant, however I personally do not like the intermingled style but rather like to order by access and by declaration type. Readability is more important to me as brevity. So I would have a section "public methods", "private attributes" and so on and I format them as such:

class A
{
public: // methods
private: // methods
private: // attributes
};

This of course also generates redundant access declarations. Also, I like putting "public" stuff first because that's most important to users of the class. So, I need an access specifier at the beginning anyway. And I put "public" at the beginning of a "struct" as well.

Answer 4

If you are very familiar with all the default access levels then you probably won't see any difference in readability if you omit them whenever they are unnecessary.

However you will find that many people you work with aren't 100% sure about the default access level rules. This is especially true for people who regularly use different languages where the rules might be different in the different languages. As a result they might get the rules mixed up.

Always specifying the access is the safest option, if only to help the people you work with have one less thing to worry about.

Answer 5

I almost always arrange my classes backwards from yours: Public interface first, any protected interface second, and private data last. This is so that users of my classes can simply look at the public and protected interfaces at the top and need not look at the private data at all. Using that order then there's no possible redundancy and the question become moot.

If you prefer to organize yours in the way you outlined, I believe being explicit far outweighs the gain one of line of code. This way it's completely obvious to code readers what the intention is (for example if you change a struct to a class or the reverse at any point).

Answer 6

I personally think that being very explicit is generally a good thing. The extra line of code is a small price to pay for the clarity that it adds.

In addition, it allows you to easily reorder your members (private must be first if it's omitted, which is really "backwards" from what you'd expect). If you reorder, and there's a private: modifier in place, other developers are less likely to break something.