Good evening
In the thread "Merging of completely unreviewed drivers" I got reminded
of the "use tabs not spaces"-mentality.
My question is: why?
The tab-character serves us well as a indent-indicator, but for some
reason there has been focus on its relation to spaces. On the question
"How long should a line at maximum be?" it is relevant (the question is
not [1]). So it is set to be as wide as 8 spaces, but when did it become
a replacement for 8 spaces? Why hinder a developer who prefer 2, 4, 6 or
any other != 8 width? 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", that is possible + easier to write
code-checkers [2].
Or are we really that concerned about the disk-space? ;)
2 cents away...
/Richard Knutsson
[1] As has been pointed out by many, it is the complexity that matters
(code-checker). A short line can be overly complicated and still under
80 lines and vice versa. Let the editors handle the long lines for the
author (even I should be able to write a decent script who can decide
where to chop-off the line).
[2] As it is now, it can look like the indentation is ex. ... 2, 2, 5,
3, 3... because the second line is split up. (I think it should have
been 2, 2, 2, 3, 3 (or even better: 2, 2, 3, 3 ))
Richard Knutsson <[email protected]> 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.
> 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.
> that is
> possible + easier to write code-checkers [2].
I doubt it.
> Or are we really that concerned about the disk-space? ;)
Unpacked sources will be much bigger with not tabs, sure.
--
Krzysztof Halasa
Krzysztof Halasa wrote:
> Richard Knutsson <[email protected]> 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.
>
>> 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
On Feb. 24, 2008, 7:40 -0800, Richard Knutsson <[email protected]> wrote:
> Krzysztof Halasa wrote:
>> Richard Knutsson <[email protected]> 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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
Richard Knutsson <[email protected]> writes:
>> 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?
Syntactic indentation vs alignment (including comments after
non-blank, values for struct initialization etc, split lines too).
> Hopefully there won't be that many, so there
> is just to delete the tabs it added and replace it with spaces.
Actually tabs "should" be used for indentation at start of the
line, then spaces. "Ideally" :-)
I.e., something like
<TAB> if (cond && (cond2 ||
<TAB> _____________cond3))
<TAB> <TAB> do_something();
Underline = space.
Perhaps some day...
> Exactly! But then we can remove the "we use 8 wide tabs in the kernel"
> in CodeStyle.
I'm not sure it's practically possible now.
>> Unpacked sources will be much bigger with not tabs, sure.
>>
> Without no tabs at all, you mean?
With spaces in place of all tabs.
All tabs converted to spaces = 20% more?
"Alignment" tabs converted to spaces? How cares how much more would it
take if it's the correct thing. Except that it's not very practical at
this point.
--
Krzysztof Halasa
Why do people even respond to these trolls...?
-Miles
--
Success, n. The one unpardonable sin against one's fellows.
Benny Halevy wrote:
> On Feb. 24, 2008, 7:40 -0800, Richard Knutsson <[email protected]> wrote:
>
>> Krzysztof Halasa wrote:
>>
>>> Richard Knutsson <[email protected]> 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.
>
Don't know what to say more then: Yup! :)
But the CodeStyle-document and checkpatch.pl does not agree with that.
Krzysztof Halasa wrote:
> Richard Knutsson <[email protected]> writes:
>
>
>>> 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?
>>
>
> Syntactic indentation vs alignment (including comments after
> non-blank, values for struct initialization etc, split lines too).
>
>
'alignment', that's the word, thanks!
>> Hopefully there won't be that many, so there
>> is just to delete the tabs it added and replace it with spaces.
>>
>
> Actually tabs "should" be used for indentation at start of the
> line, then spaces. "Ideally" :-)
>
> I.e., something like
> <TAB> if (cond && (cond2 ||
> <TAB> _____________cond3))
> <TAB> <TAB> do_something();
>
> Underline = space.
>
> Perhaps some day...
>
>
>> Exactly! But then we can remove the "we use 8 wide tabs in the kernel"
>> in CodeStyle.
>>
>
> I'm not sure it's practically possible now.
>
Well, can always patch CodeStyle and checkpatch.pl and then see what the
rest thinks.
Think checkpatch is fairly easy to "fix". It seems to have all the lines
in an array so there is only a need to check the indent-depth of the
line above and see if the current is the same with only spaces afterwards.
The idea was to reply with a patch, but it is bit late now.
>
>>> Unpacked sources will be much bigger with not tabs, sure.
>>>
>>>
>> Without no tabs at all, you mean?
>>
>
> With spaces in place of all tabs.
>
> All tabs converted to spaces = 20% more?
> "Alignment" tabs converted to spaces? How cares how much more would it
> take if it's the correct thing. Except that it's not very practical at
> this point.
>
Would guess more...
The reason I reacted were because checkpatch.pl complained about a:
<tab><tab>foo(int a,
<tab><tab>____int b)
with the "use tabs not spaces". There is little point in patching this
stuff but lets not make it worse (IMHO).
Miles Bader wrote:
> Why do people even respond to these trolls...?
>
> -Miles
>
Obviously, this must to have been discussed before, with a clear
conclusion. Unfortunately, I have not, during my ~2 years on the list,
seen anything of the sort and would like to, in that case, request a
small direction and apologize for the noise.
Richard "_not_ all knowing" Knutsson
BTW, your question:
* they like to be helpful
* they find the question reasonable
* they like furry animals
...
Sorry, am tired, but if you like I can keep you posted when I come up
with more reasons.
On Feb. 25, 2008, 13:40 -0800, Richard Knutsson <[email protected]> wrote:
> Benny Halevy wrote:
>> On Feb. 24, 2008, 7:40 -0800, Richard Knutsson <[email protected]> wrote:
>>
>>> Krzysztof Halasa wrote:
>>>
>>>> Richard Knutsson <[email protected]> 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.
>>
> Don't know what to say more then: Yup! :)
>
> But the CodeStyle-document and checkpatch.pl does not agree with that.
>
I know :(
If there's enough interest I can take a stab at seeing what it'd
take to implement such a check in checkpatch.pl
Benny
On Feb 25 2008 23:13, Richard Knutsson wrote:
> Miles Bader wrote:
>> Why do people even respond to these trolls...?
>>
> Obviously, this must to have been discussed before, with a clear conclusion.
It has been discussed before, at http://lkml.org/lkml/2007/11/12/19 .
What is really frustrating is that some of the people which _do_
enforce one style of the two (tabs-only or tabs-spaces) have only
indirectly voiced their preferred style, as in
http://lkml.org/lkml/2008/1/19/67 .
Often it was just (1)"checkpatch flagged your spaces, hence they are
wrong" instead of (2)"in my tree, I only take tabs-only patches".
Now back to coding, oh and don't forget send a patch for CodingStyle
since a mail without one is often taken even less seriously.
Jan Engelhardt <[email protected]> writes:
> Now back to coding, oh and don't forget send a patch for CodingStyle
> since a mail without one is often taken even less seriously.
Someone with a patch to Emacs to use tabs for ident + spaces for
alignment maybe? :-)
--
Krzysztof Halasa
Jan Engelhardt wrote:
> On Feb 25 2008 23:13, Richard Knutsson wrote:
>
>> Miles Bader wrote:
>>
>>> Why do people even respond to these trolls...?
>>>
>>>
>> Obviously, this must to have been discussed before, with a clear conclusion.
>>
>
> It has been discussed before, at http://lkml.org/lkml/2007/11/12/19 .
>
> What is really frustrating is that some of the people which _do_
> enforce one style of the two (tabs-only or tabs-spaces) have only
> indirectly voiced their preferred style, as in
> http://lkml.org/lkml/2008/1/19/67 .
>
> Often it was just (1)"checkpatch flagged your spaces, hence they are
> wrong" instead of (2)"in my tree, I only take tabs-only patches".
>
>
> Now back to coding, oh and don't forget send a patch for CodingStyle
> since a mail without one is often taken even less seriously.
>
What can I say? Doh! Am a bit surprised I had totally missed it during
the mailbox-cleanups (to prevent lock-down).
Thank you! for the heads-up.
Richard Knutsson