I'd like to blog about a point of code indentation. I have a strong and unusual opinion on this topic, that the way that most people do it is ... less than best.

I suspect that about half of the readers will not want to read further, since they already know the right way to indent code (the way that they do it already, whatever that may be) and the other half won't want to read further, for fear of getting involved in the religious wars, lest the nits that I pick infest them too. But anyway, though de gustibus non est disputandum (that's Latin for there's no accounting for taste), consider the following as an option.

It's worth keeping in mind that the style that you find "best" may only be so because you are used to it.  Also consider the forces that drive code styles. For instance, limited screen space was once a much bigger bottleneck than now. Class and method names have become longer and more descriptive. Renaming methods or re-ordering parameters without automated tools was difficult. Common style across a team encourages readability, so a compromise style that everyone can live with is better than each using their own favourite style.

When I first saw the style that StyleCop uses, I disliked it a lot, mostly because it was so different. But it grew on me through familiarity, and I think it has merit simply due to being broadly known and automatically verifiable.

I want to address one particular matter on which I disagree with most. Here's a line of code similar to what I see sometimes:

someObject.CallTheMethodWithMultipleParameters(aValue, bValue,
                                               cValue, dValue);

See how "cValue" is lined up with aValue? That's a usual style. I prefer a constant indentation of one stop for the following line, as below, for reasons that I will explain below

someObject.CallTheMethodWithMultipleParameters(
    aValue, bValue, cValue, dValue);

There are in fact a few ways in which you can "account" for it, tot up some logical factors, rather than going with gut feel which is overly swayed by familiarity. Like many well-travelled coders, I was challenged to step up my coding skills to a more serious level  by Steve McConnell's excellent book Code Complete I see echoes of this book in later works like Clean Code  but McConnell's level of rigour is hard to match. Nothing in Code Complete is presented as "the right way just because I say so and I know best".

McConnell's goes into reasons for preferring  indentation strategies, and suggest that all other things being equal, we should prefer code layout that is consistent and maintainable.

Unfortunately, the common indentation above is neither. It is inconsistent, since the trailing line is essentially indented a random number of spaces, depending on the names of the object and method on the line above. If you think that the upper line looks "neater" since things line up, consider this random sequence of indentation.  Maybe it looks neat to you but not to me.

someObject.CallTheMethodWithMultipleParameters(aValue, bValue,
                                               cValue, dValue);
someOther.Call(aValue, bValue,
               cValue, dValue);

lastObject.CallADifferentMethod(aValue, bValue,
                                cValue, dValue);

It is less maintainable, since the trailing line has been given an avoidable reason to change. When the variable or method on the line  above is renamed, its indentation has been made incorrect. If the trailing line is always indented one stop, changes to the line above it do not affect it.

Also, it's a waste of screen space. I've seen code broken onto three of four lines instead of two just because the trailing text was all squashed up, over at the right-hand edge of the screen. It's often incorrect too by its own standards, either by getting it wrong by a space or two initally, or by not doing the maintainence.

I suspect that this issue has become worse over the years, as variable and method names have become longer and more descriptive. You do get used to constant trailing line indentation, definitely. The eye learns to find the trailing line at the same place every time.

I'm not suggesting that you break your team's coding standard. But next time you find yourself making one or coding without one, you could question some of your habits.