Why don't people indent C++ access specifiers/

Question

I often see stuff like this:

class SomeClass {
public:
    void someMethod();
private:
    int someMember;
};

This seems totally unnatural to me (the same applies to case-statements when using switch). I expected something like this, when i started using C++ (it's been a long time since then, but i am still wondering):

class SomeClass {
    public:
        void someMethod();
    private:
        int someMember;
};

Is there a funded reason to break (otherwise) consistent indentation rules?

Answer 1

Increasing indentation normally reflects entry to a new nested scope, whereas both access specifiers and switch case statements don't vary the scope (the same is true of labels generally). Access specifiers can be optional in that you may start implementing a class or struct and have all members only need the implied access (i.e. private and public respectively), but then the code evolves and you need to add a specifier for the non-implied-access members: is it really worth having to suddenly change the indentation on all members? Again, there's no nested scope, so I think that would be actively misleading.

If you work on fixed-width terminals and wrap your lines accordingly, reindenting's a pain. But, it is useful to have the access specifiers stand out from the members, which means putting them back to the left somewhere - either in line with the class keyword or part-way there.

Personally, I do this:

class X
{
  public:
    int member_function()
    {
        switch (expression)
        {
          case X:
            return 6;

          default:
          {
            int n = get_value() / 6;
            return n * n;
          }
        }
    }

  private:
    int member_variable_;
};

Why do I not indent code for each case further? I can't claim what I do is particularly logical, but factors include:

• I don't want to deemphasise the general switch/case indentation, as visually communicating the extent of the switch is important to quickly understanding the code
• I'm happy just to put the { and } around existing case code - more like a comment "hey, I need a scope" - rather than feeling compelling to indent everything further, which doesn't make much sense even to me but kind of feels right - I like having the code for each case line up
• some compilers do warn if you introduce new variables inside a case statement without introducing a scope, even if there are no cases when the variable is later used potentially uninitialised
• I'm an 80-column coder generally, with 4 space indents normally, so being inside a switch - and thus obviously a function - means remaining columns are valuable.

Same for class/struct:

• I want to scan the left column and quickly find the end of the class, or easily count the small classes on screen or in a printout; access specifiers at exactly the same indentation level deemphasise the class keyword, but it does help to have them visually distinct from the members (if the class/struct is more than a few lines, I also add a blank line beforehand)
• I don't want to change existing class/struct member indentation when I introduce a private or protected specifier

In conclusion: lots of small factors go into developing people's indentation preferences, and if you want to be a C++ programmer in a corporate environment - especially a contractor - you just have to go with the flow and be able to change your own style sometimes too (e.g. I'm stuck in camelCaseLand right now, with public member variables starting with an uppercase letter - yikes!). Don't sweat it - it's not worth it.

Answer 2

It's all about scoping and grouping of branches. If these are not affected, then do not add an indentation level.

Take for instance the following:

if( test == 1 ) {
    action1( );
} else if( test == 2 ) {
    action2( );
} else {
    action3( );
}

Take note of the levels of the statement blocks. Now re-write it as a case statement with indented cases:

switch( test ) {
    case 1:
        action1( );
        break;
    case 2:
        action2( );
        break;
    default:
        action3( );
        break;
}

This does the exact same functionally, yet the indentations don't match of my actions. And I think it is this inconsistency that finally made me change to dropping the extra spurious indentation. (Even though I don't mind the half-indenting proposed by others, mind you.)

Answer 3

Two possible reasons:

• that's how Bjarne Stroustrup indents them in his books

• most text editors indent them that way automatically

Answer 4

There are very few access modifier lines per class, and most editors color modifiers differently from everything else. They stand out plenty on their own, so why add unnecessary tabs?