I often see stuff like this:
class SomeClass {
public:
void someMethod();
private:
int someMember;
};
This seems totally unnatural
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?
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:
switch
/case
indentation, as visually communicating the extent of the switch is important to quickly understanding the code{
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 upcase
statement without introducing a scope, even if there are no cases when the variable is later used potentially uninitialisedswitch
- and thus obviously a function - means remaining columns are valuable.Same for class
/struct
:
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)/
struct member indentation when I introduce a private
or protected
specifierIn 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.
As mentioned earlier (though argued for non-indented access modifiers), access modifiers form logical blocks. While these are at the same level as the class braces, they are special.
Thus it's useful to have indentation to clearly show where each block starts and ends.
I personally think it makes the code clearer. Others will dissagree.
This is a rather subjective question.
Most editors Indent them automatically, for me i leave them as they are in small classes or small files or short switch statements but for long ones or long file with many long switch statements i use more indentation for easier readability
I sometimes do this which i feel as old style
Class CClass
{
CClass();
~CClass();
Public:
int a;
Private:
int b;
};
CClass::CClass
{
TODO code;
}
This sometimes make it easier when a file may contain more than 20 or 50 function so u can easily spot the beginning of every function