LKML Archive on
help / color / mirror / Atom feed
From: Benny Halevy <>
To: Richard Knutsson <>
Cc: Krzysztof Halasa <>,
	Linux kernel mailing list <>
Subject: Re: Tabs, spaces, indent and 80 character lines
Date: Sun, 24 Feb 2008 08:15:08 -0800	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Feb. 24, 2008, 7:40 -0800, Richard Knutsson <> wrote:
> Krzysztof Halasa wrote:
>> Richard Knutsson <> writes:
>>> Why hinder a developer who prefer
>>> 2, 4, 6 or any other != 8 width?
>> I guess we could use tabs only at the line start, for indentation
>> only. Rather hard to implement, most text editors can't do that yet.
> You mean for split lines? Hopefully there won't be that many, so there 
> is just to delete the tabs it added and replace it with spaces.

IMO, tabs SHOULD be used for syntactic indentation and spaces for
decoration purpose only.  I.e. a line should start with a number of tabs
equal to its nesting level and after that only spaces should be used.
for example, the following code

for (i = 0; i < n; i++) printk("a very long format string", some, parameters);

should be formatted like this:

<tabs...>for (i = 0; i < n; i++)
<tabs...><tab>printk("a very long format string",
<tabs...><tab>       some, parameters);

this will show exactly right regardless of your editor's tab expansion setting
as long as you use fixed-width fonts - where the screen width of the space character
is equal to all other characters.  Once you start using tabs instead of spaces
to push text right so it appears exactly below some other text on the line above
you make a dependency on *your* editor's tab expansion policy and that's not very
considerate for folks who prefer a different one.

>>> By only using tabs as indents, and
>>> changing the CodeStyle to be something like "maximum 80
>>> characters-wide lines, with a tab-setting of 8 spaces",
>> This changes nothing.
> Exactly! But then we can remove the "we use 8 wide tabs in the kernel" 
> in CodeStyle.
>>> that is
>>> possible + easier to write code-checkers [2].
>> I doubt it.
> Easier to write code-checkers? OK, maybe not. Just that I got hit by 
> this problem at a time when I wrote a simple checker (don't remember its 
> purpose).
>>> Or are we really that concerned about the disk-space? ;)
>> Unpacked sources will be much bigger with not tabs, sure.
> Without no tabs at all, you mean? Don't want to think about that 
> scenario, but with this suggestion, I would estimate maybe 0,5 - 1% bigger.
> Thanks for your input
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to
> More majordomo info at
> Please read the FAQ at

  reply	other threads:[~2008-02-24 16:15 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-24  0:48 Richard Knutsson
2008-02-24 14:56 ` Krzysztof Halasa
2008-02-24 15:01   ` Miles Bader
2008-02-25 22:13     ` Richard Knutsson
2008-02-26  2:00       ` Jan Engelhardt
2008-02-26 15:50         ` Krzysztof Halasa
2008-02-26 22:03         ` Richard Knutsson
2008-02-24 15:40   ` Richard Knutsson
2008-02-24 16:15     ` Benny Halevy [this message]
2008-02-25 21:40       ` Richard Knutsson
2008-02-26  0:47         ` Benny Halevy
2008-02-24 17:36     ` Krzysztof Halasa
2008-02-25 21:56       ` Richard Knutsson

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \
    --subject='Re: Tabs, spaces, indent and 80 character lines' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).