Is it confusing to omit the "private" keyword from a class definition?

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

clas开发者_JAVA技巧s 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?

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.

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.

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.

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.

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.

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

I often see the public part of a class/struct definition first, thus the protected/private stuff comes later.

It make sense, as a header file is meant to show what the public interface for your class actually is.

At the same time, why not use struct? public by default...

Still, it never hurts to be extra clear in your code as to what is going on. This is the same reason why I avoid the ternary operator and still put in the braces for an if statement that only has one line of code after it.

The most pressing issue though, is what are your companies code standards? Like them or not, that's the standard style you should do for your company, if they say do it such a way, you do it such a way.