Linus Torvalds <torvalds@xxxxxxxx> writes:
> On Sun, 22 Oct 2006, Jakub Narebski wrote:
>>
>> To be true I do those "whitespace cleanup" patches when I notice
>> that something is mis-aligned for _my_ tab width (2 spaces).
>
> Oh, wow.
>
> You have clearly been damaged by some nasty GNU coding style or similar.
>
> Please immediately turn tabs into 8 character hard-tabs, and read the
> kernel Documentation/CodingStyle document.
Offtopic comments.
I am from old school, so a TAB to me is always equivalent to a
run of spaces that pads up to the next column that is dividible
by 8, but there is one valid reason to occasionally take a look
at your code with unusual TAB settings to catch coding style
violations, if you _were_ following an indentation policy that
is different from what the kernel and git uses.
Aside from the textual comparison order habit (aka "never use >
or >= comparison operators") that everybody hates (and I've been
trying not to inroduce new ones, albeit slowly), I have picked
up two other "unusual" coding style habits, which I deliberately
have stayed away from applying to the code I write for git.
They both relate to the way the code is indented; unlike the
textual order comparison one, they do not affect readability to
me that much and it is easier for me to shake them when I want
to be.
They are:
- There is no "aligning" between two lines, other than the case
in which they start with _identical_ substring. Not just
that a TAB does not necessarily look the same as spaces to
the next display column that is divisible by 8 by everybody;
think about proportinal fonts.
When you take this position, there is only one thing you can
do when your logical line extends over more than one physical
lines because it is too long. Since there is no aligning,
the only sensible thing to do is to indent it one level
deeper than the first physical line of the logical line.
Your indentation becomes like this:
<BOL><TAB>if (very long expression that extends over<EOL>
<BOL><TAB><TAB>more than one line) {<EOL>
<BOL><TAB><TAB>do this and do that...<EOL>
<BOL><TAB>}<EOL>
When you are following this principle (and git sources do not
and should not), viewing your code with an unusual tab width
is a good way to check the coding style violation.
- If you have to split a long expression over multiple lines,
split the line _before_ a binary operator, not after, so when
you turn your head sideways 90 degrees, you would see the
parse tree of the expression:
foo = a-term
* (a-very-very-long-expression-term
+ yet-another-term);
If there _were_ alignment, this would perhaps look like this:
foo = a-term
* ( a-very-very-long-expression-term
+ yet-another-term);
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html