Hi kernel hackers,
yes, i know http://www.purists.org/linux/#indent .
my question is just: what's the matter of NOT using tabs instead of
spaces? i think there must be one, otherwise everybody would use tabs.
I know the thing about "more than 3 levels of indention *suck*" (but i'm
not sure if i have really understand this yet in my coding style, but
who cares..), but i like tab characters more than spaces, simply because
it removes all the discussion about the best indention width. some
people use ~180 character-consoles, some use 80 ones.Whats the reason of
not giving the freedom to choose whatever he likes?
i don't want to change anything, i just like to know WHY people use
spaces. are they somehow unportable? (i don't think so)
Felix Domke <[email protected]> writes:
> i don't want to change anything, i just like to know WHY people use
> spaces. are they somehow unportable? (i don't think so)
<http://www.jwz.org/doc/tabs-vs-spaces.html>
--
Russ Allbery ([email protected]) <http://www.eyrie.org/~eagle/>
On Sun, Dec 29, 2002 at 07:33:20PM -0800, Russ Allbery wrote:
> Felix Domke <[email protected]> writes:
>
> > i don't want to change anything, i just like to know WHY people use
> > spaces. are they somehow unportable? (i don't think so)
>
> <http://www.jwz.org/doc/tabs-vs-spaces.html>
Quouting from that page:
That ensures that, even if I happened to insert a literal tab in the
file by hand (or if someone else did when editing this file earlier),
those tabs get expanded to spaces when I save.
If you are using a source management system, pretty much *any* source
management system, doing this will cause all the lines to be "rewritten"
if they had tabs. The fact that this person would advocate changing
code that they didn't actually change shows a distinct lack of clue.
No engineer who works for an even semi-pro company would dream of doing
this. At BitMover, anyone who seriously advocated this for more than
a day would be fired.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
On Sun, Dec 29, 2002 at 07:43:03PM -0800, Larry McVoy wrote:
> On Sun, Dec 29, 2002 at 07:33:20PM -0800, Russ Allbery wrote:
> > Felix Domke <[email protected]> writes:
> >
> > > i don't want to change anything, i just like to know WHY people use
> > > spaces. are they somehow unportable? (i don't think so)
> >
> > <http://www.jwz.org/doc/tabs-vs-spaces.html>
>
> Quouting from that page:
> That ensures that, even if I happened to insert a literal tab in the
> file by hand (or if someone else did when editing this file earlier),
> those tabs get expanded to spaces when I save.
>
> If you are using a source management system, pretty much *any* source
> management system, doing this will cause all the lines to be "rewritten"
> if they had tabs. The fact that this person would advocate changing
> code that they didn't actually change shows a distinct lack of clue.
> No engineer who works for an even semi-pro company would dream of doing
> this. At BitMover, anyone who seriously advocated this for more than
> a day would be fired.
well, he DID work at netscape...
j.
--
toyota power: http://indigoid.net/
Larry McVoy <[email protected]> writes:
> On Sun, Dec 29, 2002 at 07:33:20PM -0800, Russ Allbery wrote:
>> <http://www.jwz.org/doc/tabs-vs-spaces.html>
> Quouting from that page:
> That ensures that, even if I happened to insert a literal tab in the
> file by hand (or if someone else did when editing this file earlier),
> those tabs get expanded to spaces when I save.
> If you are using a source management system, pretty much *any* source
> management system, doing this will cause all the lines to be "rewritten"
> if they had tabs. The fact that this person would advocate changing
> code that they didn't actually change shows a distinct lack of clue.
Yeah, that recommendation always bugged me too. I would never do that; if
you really want to enforce something like that, the proper place is in a
pre-checkin transform in your source management system so that everything
that actually hits the source management database has no tabs in it. Not
in individual editors.
But the rest of the message is a good summary of the issues, as far as I'm
concerned.
I'll add one additional issue, and the one that bugs me the most in
practice about tabs. Tabs make patches a pain in the neck to read,
because they change the indentation of the lines in a diff so that it no
longer matches the original indentation. In particularly pathological
cases, they can even make an indented line even with an unintended line.
--
Russ Allbery ([email protected]) <http://www.eyrie.org/~eagle/>
On Mon, Dec 30, 2002 at 03:29:04AM +0100, Felix Domke wrote:
> Hi kernel hackers,
>
> yes, i know http://www.purists.org/linux/#indent .
>
> my question is just: what's the matter of NOT using tabs instead of
> spaces? i think there must be one, otherwise everybody would use tabs.
>
> I know the thing about "more than 3 levels of indention *suck*" (but i'm
> not sure if i have really understand this yet in my coding style, but
> who cares..), but i like tab characters more than spaces, simply because
> it removes all the discussion about the best indention width. some
> people use ~180 character-consoles, some use 80 ones.Whats the reason of
> not giving the freedom to choose whatever he likes?
>
> i don't want to change anything, i just like to know WHY people use
> spaces. are they somehow unportable? (i don't think so)
spaces are a workaround for broken editors. But Linux developers have a
"use the best tool for your job" approach so we don't care :)
As someone pointed to a paper by a mozilla hacker in this thread here's
another advice: don't use mozilla to send non mime-encoded patches, they
even implemented their brain-dead tab expansion policy in their mailer.
*sigh*
Previously Russ Allbery wrote:
> <http://www.jwz.org/doc/tabs-vs-spaces.html>
Well, I disagree: http://www.wiggy.net/rants/tabsvsspaces.xhtml
Wichert.
--
Wichert Akkerman <[email protected]> http://www.wiggy.net/
A random hacker
> Well, I disagree: http://www.wiggy.net/rants/tabsvsspaces.xhtml
In my opinion, indentation in any form is irritating.
I find a left hand margin that jumps around, and in deeply nested
loops effectively makes a 132 column terminal in to an 80 column
terminal, completely pointless.
Overall, it doesn't help me to follow the program flow at all, if I
have to scroll excessively just to see lines that would be visible
without scrolling if only there were not ~40 blank columns on the
left hand side of the terminal.
John.
Previously John Bradford wrote:
> In my opinion, indentation in any form is irritating.
So set your tabwidth/shiftwidth/whatever to 0 (or 1, at least vim
does not seem to allow you to set a zero shiftwidth).
> I find a left hand margin that jumps around, and in deeply nested
> loops effectively makes a 132 column terminal in to an 80 column
> terminal, completely pointless.
Well, I disagree. But I agree that the amount of indenting used is
a highly personal thing, and I find forcing a set limit by demanding
people use spaces a bad practice. But I don't do any kernel work,
so my opinion is probably of little value here.
Wichert.
--
Wichert Akkerman <[email protected]> http://www.wiggy.net/
A random hacker
On Mon, 30 Dec 2002, John Bradford wrote:
> > Well, I disagree: http://www.wiggy.net/rants/tabsvsspaces.xhtml
>
> In my opinion, indentation in any form is irritating.
> Overall, it doesn't help me to follow the program flow at all,
Code like that definately should be indented. Preferably 6 foot down.
Rik
--
Bravely reimplemented by the knights who say "NIH".
http://www.surriel.com/ http://guru.conectiva.com/
Current spamtrap: <a href=mailto:"[email protected]">[email protected]</a>
On Mon, Dec 30, 2002 at 12:49:33PM +0000, John Bradford wrote:
> > Well, I disagree: http://www.wiggy.net/rants/tabsvsspaces.xhtml
>
> In my opinion, indentation in any form is irritating.
I disagree. Negative tab indentation (where you start off on the right
hand side of the screen and tab or space towards the left) is obviously
the most natural form. We should all be using it - it'll make the kernel
source _lots_ more readable. In fact, I'll start converting the kernel
sources now. ;-)
--
Russell King ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
On Mon, Dec 30, 2002 at 12:49:33PM +0000, John Bradford wrote:
> > Well, I disagree: http://www.wiggy.net/rants/tabsvsspaces.xhtml
> In my opinion, indentation in any form is irritating.
The devfs source code is --> that way.
Dave
--
| Dave Jones. http://www.codemonkey.org.uk
| SuSE Labs
On Mon, Dec 30, 2002 at 01:28:57PM +0100, Wichert Akkerman wrote:
> Previously Russ Allbery wrote:
> > <http://www.jwz.org/doc/tabs-vs-spaces.html>
>
> Well, I disagree: http://www.wiggy.net/rants/tabsvsspaces.xhtml
And I agree with your disagreement. And it's useful to compare your
rant with his rant side by side, just looking at that I can guess I'd
rather fix bugs in your code than his.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
<quote who="Dave Jones">
> On Mon, Dec 30, 2002 at 12:49:33PM +0000, John Bradford wrote:
> > > Well, I disagree: http://www.wiggy.net/rants/tabsvsspaces.xhtml
> > In my opinion, indentation in any form is irritating.
>
> The devfs source code is --> that way.
>
IMHO and in my personal projects I use the following indenting rules:
1) use TABs for _indentation_
2) use SPACEs for aligning
here is an exaple:
<tab><tab>if (cond) {
<tab><tab><tab>dosometing;
<tab><tab><tab>printf("This is foo: '%s', and this bar: '%d'",
<tab><tab><tab> foo, bar);
where tabs are explicitated, while spaces not.
I think this way combines both tab and spaces advantages, allowing each coder
to have its own indentation width, but NEVER destroing the aspect of the code.
This is only my opinion :-P
--
Emiliano 'AlberT' Gabrielli
dip. di Fisica
2? Universit? di Roma "Tor Vergata"
Em Mon, Dec 30, 2002 at 07:53:22PM +0100, Emiliano Gabrielli escreveu:
>
> <quote who="Dave Jones">
> > On Mon, Dec 30, 2002 at 12:49:33PM +0000, John Bradford wrote:
> > > > Well, I disagree: http://www.wiggy.net/rants/tabsvsspaces.xhtml
> > > In my opinion, indentation in any form is irritating.
> >
> > The devfs source code is --> that way.
> >
>
> IMHO and in my personal projects I use the following indenting rules:
>
> 1) use TABs for _indentation_
> 2) use SPACEs for aligning
>
> here is an exaple:
>
> <tab><tab>if (cond) {
> <tab><tab><tab>dosometing;
> <tab><tab><tab>printf("This is foo: '%s', and this bar: '%d'",
> <tab><tab><tab> foo, bar);
>
> where tabs are explicitated, while spaces not.
>
>
> I think this way combines both tab and spaces advantages, allowing each coder
> to have its own indentation width, but NEVER destroing the aspect of the code.
>
> This is only my opinion :-P
I second that.
- Arnaldo
This problem is as old as the typewriter itself. The trouble is that a
Tab character doesn't have a fixed size - some set it to 3 characters
wide, some to 4 some to 8, or whatever.
The 'indent' program was written a couple of decades ago, to pretty
print C code. It has a 'GNU' standard, but I'm not aware of a 'Linux'
standard. Anyhoo, the only way to prevent indentation wars is to use
spaces, not tabs and to set 'diff' to ignore white space when comparing
files...
Arnaldo Carvalho de Melo wrote:
> Em Mon, Dec 30, 2002 at 07:53:22PM +0100, Emiliano Gabrielli escreveu:
>
>><quote who="Dave Jones">
>>
>>>On Mon, Dec 30, 2002 at 12:49:33PM +0000, John Bradford wrote:
>>> > > Well, I disagree: http://www.wiggy.net/rants/tabsvsspaces.xhtml
>>> > In my opinion, indentation in any form is irritating.
>>>
>>>The devfs source code is --> that way.
>>>
>>
>>IMHO and in my personal projects I use the following indenting rules:
>>
>>1) use TABs for _indentation_
>>2) use SPACEs for aligning
>>
>>here is an exaple:
>>
>><tab><tab>if (cond) {
>><tab><tab><tab>dosometing;
>><tab><tab><tab>printf("This is foo: '%s', and this bar: '%d'",
>><tab><tab><tab> foo, bar);
>>
>>where tabs are explicitated, while spaces not.
>>
>>
>>I think this way combines both tab and spaces advantages, allowing each coder
>>to have its own indentation width, but NEVER destroing the aspect of the code.
>>
>>This is only my opinion :-P
>
>
> I second that.
>
> - Arnaldo
> -
> 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/
>
--
------------------------------------------------------------------------
Herman Oosthuysen
B.Eng.(E), Member of IEEE
Wireless Networks Inc.
http://www.WirelessNetworksInc.com
E-mail: [email protected]
Phone: 1.403.569-5687, Fax: 1.403.235-3965
------------------------------------------------------------------------
I think the previously proposed solution solves the issues you raised.
> This problem is as old as the typewriter itself. The trouble is that a
> Tab character doesn't have a fixed size - some set it to 3 characters
> wide, some to 4 some to 8, or whatever.
With the proposed solution, that doesn't matter.
>
> The 'indent' program was written a couple of decades ago, to pretty
> print C code. It has a 'GNU' standard, but I'm not aware of a 'Linux'
> standard. Anyhoo, the only way to prevent indentation wars is to use
> spaces, not tabs and to set 'diff' to ignore white space when comparing
> files...
Why not use tabs and spaces like proposed and let everyone see the file
the way they want to?
--Zac
>
> Arnaldo Carvalho de Melo wrote:
> > Em Mon, Dec 30, 2002 at 07:53:22PM +0100, Emiliano Gabrielli escreveu:
> >
> >><quote who="Dave Jones">
> >>
> >>>On Mon, Dec 30, 2002 at 12:49:33PM +0000, John Bradford wrote:
> >>> > > Well, I disagree: http://www.wiggy.net/rants/tabsvsspaces.xhtml
> >>> > In my opinion, indentation in any form is irritating.
> >>>
> >>>The devfs source code is --> that way.
> >>>
> >>
> >>IMHO and in my personal projects I use the following indenting rules:
> >>
> >>1) use TABs for _indentation_
> >>2) use SPACEs for aligning
> >>
> >>here is an exaple:
> >>
> >><tab><tab>if (cond) {
> >><tab><tab><tab>dosometing;
> >><tab><tab><tab>printf("This is foo: '%s', and this bar: '%d'",
> >><tab><tab><tab> foo, bar);
> >>
> >>where tabs are explicitated, while spaces not.
> >>
> >>
> >>I think this way combines both tab and spaces advantages, allowing each coder
> >>to have its own indentation width, but NEVER destroing the aspect of the code.
> >>
> >>This is only my opinion :-P
> >
> >
> > I second that.
> >
> > - Arnaldo
> > -
> > 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/
> >
>
>
hi,
> This problem is as old as the typewriter itself. The trouble is that
> a Tab character doesn't have a fixed size - some set it to 3
> characters wide, some to 4 some to 8, or whatever.
>
> The 'indent' program was written a couple of decades ago, to pretty
> print C code. It has a 'GNU' standard, but I'm not aware of a 'Linux'
> standard. Anyhoo, the only way to prevent indentation wars is to use
> spaces, not tabs and to set 'diff' to ignore white space when
> comparing files...
Anyhow, sorry, i really can't understand that. What could be more
"indention war preventing" that letting everybody use his own indention
width?
There are two main aspects of *not* using tabs:
- editors mess them up. but: use an *editor*. not a word processor.
kernel source's line endings are \n, not \r\n. some (windows) editors
mess them up. and nobody cares (and that's ok that way. nobody WANTS to
use an editor which messes up so simple things).
some editors don't show tabs. well. this leads to a mixup of tabs <->
spaces. but if you really fear about this, just use an editor which
supports showing tabs. joe doesn't show spaces (by default?), but i
never missed that, for example.
- aligning. well, just use spaces for aligning, tabs for indention. two
different things. two different characters.
TAB characters simply *have* no assigned width. that's the reason for
them. they are not a macro for 3/4/8 spaces.
not using spaces, in my eyes, just *takes* a possibility to
platform-independant format sourcecode on the given screensize. it gives
you nothing.
and as they might be some pitfalls (wrong aligning etc.), you can still
set the tabwidth to the one of the author. in that case, you didn't win
anything by using tabs, but you didn't loose either.
again, i was just *wondering* why everybody is using spaces, and still,
i can't find a good reason for that. if anybody shows me that, i'll
maybe start using spaces (again).
felix
On Sun, Dec 29, 2002 at 07:43:03PM -0800, Larry McVoy wrote:
> > <http://www.jwz.org/doc/tabs-vs-spaces.html>
> Quouting from that page:
> That ensures that, even if I happened to insert a literal tab in the
> file by hand (or if someone else did when editing this file earlier),
> those tabs get expanded to spaces when I save.
> If you are using a source management system, pretty much *any* source
> management system, doing this will cause all the lines to be "rewritten"
> if they had tabs. The fact that this person would advocate changing
> code that they didn't actually change shows a distinct lack of clue.
> No engineer who works for an even semi-pro company would dream of doing
> this. At BitMover, anyone who seriously advocated this for more than
> a day would be fired.
Disagreeing with that slightly - there is middle ground, but it needs
to be explicit, or at least source file type dependent. For example,
whitespace on the *end* of a line containing text can almost always be
stripped. I've had far more trouble than its worth of designers
submitting code that accidentally included whitespace at the end of
lines. They didn't even *intend* to change the line, or when they made
a change, and restored the original code, they unintentionally left
whitespace on the end. Later on in the development process, this
seemingly insignificant difference becomes significant when two
functional equivalent lines trigger to the source manager as segment
that requires a complex merge operation.
The middle ground takes the form 'this is a common mistake people make
for this specific project, and as a business case, it makes a lot more
sense to quietly handle the situation automatically.' Some design
groups force their source to be put through a mandatory automatic code
beautification/styler process during submission. As the customer, and
as the people directly familiar with the problems they experience, and
the responsibility for their choice, they *should* have the choice to
enable a process such as is described in the above URL (expanding
leading tabs to whitespace on submission).
The alternative, of course, is the choice that Linux takes. If it doesn't
meet the appropriate requirements, it doesn't get submitted.
The source manager is supposed to help you, not hinder you. For very common
situations, where responsibility for consequences can be accepted, the
source manager *should* provide the means to perform transformations of the
source code upon submission.
Firing an employee for suggesting this seems a little extreme... :-)
mark
--
[email protected]/[email protected]/[email protected] __________________________
. . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder
|\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ |
| | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada
One ring to rule them all, one ring to find them, one ring to bring them all
and in the darkness bind them...
http://mark.mielke.cc/
On Mon, Dec 30, 2002 at 09:43:19PM +0100, Felix Domke wrote:
> Anyhow, sorry, i really can't understand that. What could be more
> "indention war preventing" that letting everybody use his own indention
> width?
If everybody had exclusive ownership of code sections, and only they ever
made changes to that code in the time before, now, and after, than nothing.
In the more practical world, and especially for code architects, or
senior programmers, every user touches every other users code.
If they each adjusted their style to match the code they were editting,
this would be an unacceptable overhead. If they each casually adjusted
the style of the code to their own style and editor setting, the code
becomes a mess (different styles of indentation used within the same
function body, etc.). Also, they become tempted to indent the surrounding
code to their style (even if this introduces whitespace only changes into
the code stream) as their style may conflict.
Style should be determined per product, or at least per component. I
would say style should be determined universally, but that would not
be practical, nor would it encourage creativity.
mark
--
[email protected]/[email protected]/[email protected] __________________________
. . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder
|\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ |
| | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada
One ring to rule them all, one ring to find them, one ring to bring them all
and in the darkness bind them...
http://mark.mielke.cc/
Felix Domke wrote:
> and as they might be some pitfalls (wrong aligning etc.), you can still
> set the tabwidth to the one of the author. in that case, you didn't win
> anything by using tabs, but you didn't loose either.
>
Well, that is the problem - trying to figure out what the tab size of
the author was. It gets messy really quickly when a file was edited by
multiple authors, using multiple tab widths. It then becomes impossible
to figure out how to set the tab width to make the code indent properly.
Anyhoo, over the years, I learned not to care about it, since it is just
too trivial an issue and there are more important things to worry about.
So, if I find a page's indentation bothersome, I run it through 'indent'
for a private readable copy. I even ported 'indent' to windoze a couple
of years ago...
Previously Mark Mielke wrote:
> If they each adjusted their style to match the code they were editting,
> this would be an unacceptable overhead.
[...]
> Style should be determined per product, or at least per component
There is a contradiction there. In reality you learn to deal with
different indenting styles, especially if you live in an free software
environment. Style should be consistent within a product though.
Wichert.
--
Wichert Akkerman <[email protected]> http://www.wiggy.net/
A random hacker
On Mon, 30 Dec 2002, Herman Oosthuysen wrote:
> This problem is as old as the typewriter itself. The trouble is that a
> Tab character doesn't have a fixed size - some set it to 3 characters
> wide, some to 4 some to 8, or whatever.
>
> The 'indent' program was written a couple of decades ago, to pretty
> print C code. It has a 'GNU' standard, but I'm not aware of a 'Linux'
> standard. Anyhoo, the only way to prevent indentation wars is to use
> spaces, not tabs and to set 'diff' to ignore white space when comparing
> files...
indent itself dosen't have a 'Linux standard' BUT .../linux/scripts/Lindent
is there to get things right (in terms of CodingStyle)
I don't know if is usinging it or even if it is still current but it's a
starting point.
Yours Tony
Jan 22-25 2003 Linux.Conf.AU http://linux.conf.au/
The Australian Linux Technical Conference!
> IMHO and in my personal projects I use the following indenting rules:
>
> 1) use TABs for _indentation_
> 2) use SPACEs for aligning
>
> here is an exaple:
>
><tab><tab>if (cond) {
><tab><tab><tab>dosometing;
><tab><tab><tab>printf("This is foo: '%s', and this bar: '%d'",
><tab><tab><tab> foo, bar);
BTW, this practice is codified in Solaris developer's guidelines.
They even have a perl script called "hdrchk" which is run before
commits and tells about violations. Actually, the Sun requirement
is to have exactly 4 spaces, but it sounds a little too anal to me.
-- Pete
On Tue, Dec 31, 2002 at 12:28:37AM -0500, Pete Zaitcev wrote:
> > IMHO and in my personal projects I use the following indenting rules:
> >
> > 1) use TABs for _indentation_
> > 2) use SPACEs for aligning
> >
> > here is an exaple:
> >
> ><tab><tab>if (cond) {
> ><tab><tab><tab>dosometing;
> ><tab><tab><tab>printf("This is foo: '%s', and this bar: '%d'",
> ><tab><tab><tab> foo, bar);
>
> BTW, this practice is codified in Solaris developer's guidelines.
> They even have a perl script called "hdrchk" which is run before
> commits and tells about violations. Actually, the Sun requirement
> is to have exactly 4 spaces, but it sounds a little too anal to me.
Indeed and the reasoning is that tabs are for indentation, 4 spaces are
for continuation lines.
if (expr) {
statement;
statement;
if (really_long_expression && another_expression &&
one_more) {
statement;
}
}
You can do slightly better than that if you do it like this:
if (really_long_expression &&
another_expression && one_more) {
statement;
}
I try and get people to put the longer part of the expression on the
continuation line, your eyes will parse that better than the first way.
By the way, this sort of thing is a big deal around here, I spend a
lot of time getting people to do it all the same way. It's worth it.
The bottom line is "can I fix bugs in your code quickly?". Indentation
is part of understanding the code.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
> [[email protected]]
>
> As someone pointed to a paper by a mozilla hacker in this thread here's
> another advice: don't use mozilla to send non mime-encoded patches, they
> even implemented their brain-dead tab expansion policy in their mailer.
Uhh.
I wasn't aware of that. Maybe someone should wake up the veck that committed
the changeset by giving them a fair horrorshow tolchock on the gulliver with
the old hammer?
:)
No reall that _is_ a braindead idea.
--
Tomas Szepe <[email protected]>
On Tue, Dec 31, 2002 at 10:20:13AM +0800, Anthony J. Breeds-Taurima wrote:
> indent itself dosen't have a 'Linux standard' BUT .../linux/scripts/Lindent
> is there to get things right (in terms of CodingStyle)
Unless you don't use GNU indent but an indent that's written in a sane
codingstyle itself, like:
http://developer.berlios.de/project/?group_id=192
Sorry to fan the flames... *sigh*
I like editors that show me tabs since I can use it as a simple ruler for which block I believe myself to be in. For example:
The >- characters show a tab. Were my tabwidth other than 2, I'd have that many more '-'s.
>-struct MetaObjectGetsMetaObjectAction: public ActionBase{
>->-~MetaObjectGetsMetaObjectAction(){}
>->-MetaObjectBase* a,*b;
>->-MetaObjectGetsMetaObjectAction(MetaObjectBase* ta, MetaObjectBase* tb){
>->->-a=ta;
>->->-b=tb;
>->-}
The '>-'s are in another color (dark grey in a black terminal)
When I edit code that is written with only spaces I don't get this hint as to block-level.
The only way I can get this otherwise is to hack my editor (yech), or retab the source, which is evil and shouldn't be done.
I'm not proprosing any changes since I'm not an active kernel developer imho I've got no say in the matter and no right-to-say.
-Roberto Peon
[email protected]
---------- Original Message ----------------------------------
From: Felix Domke <[email protected]>
Date: Mon, 30 Dec 2002 21:43:19 +0100
>hi,
>
>> This problem is as old as the typewriter itself. The trouble is that
>> a Tab character doesn't have a fixed size - some set it to 3
>> characters wide, some to 4 some to 8, or whatever.
>>
>> The 'indent' program was written a couple of decades ago, to pretty
>> print C code. It has a 'GNU' standard, but I'm not aware of a 'Linux'
>> standard. Anyhoo, the only way to prevent indentation wars is to use
>> spaces, not tabs and to set 'diff' to ignore white space when
>> comparing files...
>
>Anyhow, sorry, i really can't understand that. What could be more
>"indention war preventing" that letting everybody use his own indention
>width?
>
>There are two main aspects of *not* using tabs:
> - editors mess them up. but: use an *editor*. not a word processor.
>kernel source's line endings are \n, not \r\n. some (windows) editors
>mess them up. and nobody cares (and that's ok that way. nobody WANTS to
>use an editor which messes up so simple things).
>some editors don't show tabs. well. this leads to a mixup of tabs <->
>spaces. but if you really fear about this, just use an editor which
>supports showing tabs. joe doesn't show spaces (by default?), but i
>never missed that, for example.
> - aligning. well, just use spaces for aligning, tabs for indention. two
>different things. two different characters.
>
>TAB characters simply *have* no assigned width. that's the reason for
>them. they are not a macro for 3/4/8 spaces.
>
>not using spaces, in my eyes, just *takes* a possibility to
>platform-independant format sourcecode on the given screensize. it gives
>you nothing.
>
>and as they might be some pitfalls (wrong aligning etc.), you can still
>set the tabwidth to the one of the author. in that case, you didn't win
>anything by using tabs, but you didn't loose either.
>
>again, i was just *wondering* why everybody is using spaces, and still,
>i can't find a good reason for that. if anybody shows me that, i'll
>maybe start using spaces (again).
>
>felix
>
>
>
>-
>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/
>
> indent itself dosen't have a 'Linux standard' BUT
> .../linux/scripts/Lindent
> is there to get things right (in terms of CodingStyle)
Thanks, I wasn't aware of that one, but had created my own version.
A couple more gallons of fuel to the flame :)
>From .../linux/scripts/Lindent:
indent -kr -i8 -ts8 -sob -l80 -ss -bs -psl "$@"
-psl: seams to be inconsistent with much of the kernel code.
6 == half dozen IMHO.
-sob: Ackkk! I prefer to have two blank lines between functions. I think it
just
makes things easier for the eyes to parse. But in general, I'd say respect
the
authors judgement in use of blank lines.