Tabs, spaces, indent and 80 character lines

Tabs, spaces, indent and 80 character lines

[Richard Knutsson]

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 ))

Re: Tabs, spaces, indent and 80 character lines

[Krzysztof Halasa]

Richard Knutsson <ricknu-0@student.ltu.se> 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

Re: Tabs, spaces, indent and 80 character lines

[Miles Bader]

Why do people even respond to these trolls...?

-Miles

-- 
Success, n. The one unpardonable sin against one's fellows.

Re: Tabs, spaces, indent and 80 character lines

[Richard Knutsson]

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.

Re: Tabs, spaces, indent and 80 character lines

[Jan Engelhardt]

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.

Re: Tabs, spaces, indent and 80 character lines

[Krzysztof Halasa]

Jan Engelhardt <jengelh@computergmbh.de> 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

Re: Tabs, spaces, indent and 80 character lines

[Richard Knutsson]

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

Re: Tabs, spaces, indent and 80 character lines

[Richard Knutsson]

Krzysztof Halasa wrote:
> Richard Knutsson <ricknu-0@student.ltu.se> 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

Re: Tabs, spaces, indent and 80 character lines

[Benny Halevy]

On Feb. 24, 2008, 7:40 -0800, Richard Knutsson <ricknu-0@student.ltu.se> wrote:
> Krzysztof Halasa wrote:
>> Richard Knutsson <ricknu-0@student.ltu.se> 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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: Tabs, spaces, indent and 80 character lines

[Richard Knutsson]

Benny Halevy wrote:
> On Feb. 24, 2008, 7:40 -0800, Richard Knutsson <ricknu-0@student.ltu.se> wrote:
>   
>> Krzysztof Halasa wrote:
>>     
>>> Richard Knutsson <ricknu-0@student.ltu.se> 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.

Re: Tabs, spaces, indent and 80 character lines

[Benny Halevy]

On Feb. 25, 2008, 13:40 -0800, Richard Knutsson <ricknu-0@student.ltu.se> wrote:
> Benny Halevy wrote:
>> On Feb. 24, 2008, 7:40 -0800, Richard Knutsson <ricknu-0@student.ltu.se> wrote:
>>   
>>> Krzysztof Halasa wrote:
>>>     
>>>> Richard Knutsson <ricknu-0@student.ltu.se> 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

Re: Tabs, spaces, indent and 80 character lines

[Krzysztof Halasa]

Richard Knutsson <ricknu-0@student.ltu.se> 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

Re: Tabs, spaces, indent and 80 character lines

[Richard Knutsson]

Krzysztof Halasa wrote:
> Richard Knutsson <ricknu-0@student.ltu.se> 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).