From: Junio C Hamano <junkio@cox•net>
To: Linus Torvalds <torvalds@osdl•org>
Cc: Jakub Narebski <jnareb@gmail•com>, git@vger•kernel.org
Subject: Re: [PATCH 1/4] gitweb: Whitespace cleanup - tabs are for indent, spaces are for align (2)
Date: Sun, 22 Oct 2006 15:55:59 -0700 [thread overview]
Message-ID: <7v64ec2c5c.fsf@assigned-by-dhcp.cox.net> (raw)
In-Reply-To: <Pine.LNX.4.64.0610221359090.3962@g5.osdl.org> (Linus Torvalds's message of "Sun, 22 Oct 2006 14:03:20 -0700 (PDT)")
Linus Torvalds <torvalds@osdl•org> 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);
next prev parent reply other threads:[~2006-10-22 22:56 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-10-21 15:50 [PATCH 0/4] gitweb: Improving tree view (plus some cleanups) Jakub Narebski
2006-10-21 15:52 ` [PATCH 1/4] gitweb: Whitespace cleanup - tabs are for indent, spaces are for align (2) Jakub Narebski
2006-10-22 20:22 ` Junio C Hamano
2006-10-22 20:36 ` Jakub Narebski
2006-10-22 21:03 ` Linus Torvalds
2006-10-22 21:27 ` Jakub Narebski
2006-10-22 22:55 ` Junio C Hamano [this message]
2006-10-22 23:36 ` Luben Tuikov
2006-10-21 15:53 ` [PATCH 2/4] gitweb: Do not esc_html $basedir argument to git_print_tree_entry Jakub Narebski
2006-10-21 15:53 ` [PATCH 3/4] gitweb: Improve git_print_page_path Jakub Narebski
2006-10-21 15:54 ` [PATCH 4/4] gitweb: Add '..' (up directory) to tree view if applicable Jakub Narebski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7v64ec2c5c.fsf@assigned-by-dhcp.cox.net \
--to=junkio@cox$(echo .)net \
--cc=git@vger$(echo .)kernel.org \
--cc=jnareb@gmail$(echo .)com \
--cc=torvalds@osdl$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox