Re: coding style for long conditions (WAS: Re: [PATCH 25/90] ... blinky leds!!)
On 4/6/07, Stefan Richter <[EMAIL PROTECTED]> wrote:
David Brownell wrote:
[...]
>>> 1 if (To control chain reactions, your odds
>>> 2 Improve if you've got cadmium rods) {
>>> 3 In your fission reactor
>>> 4 Their lack is a factor
>>> 5 }
>>> 6 In screams of "A meltdown! Ye gods!"
>>>
>>> Now, the former makes it hard to tell what's condition vs consequent.
>>> (Or whatever the correct technical term is in cases like these.)
>> My fu dictates that continuation lines (line 2 in this example)
>> should have more indent than line 1,
>
> Yes. Where "indent" is measured -- always!! -- in tabs.
> Documentation/Coding style is quite explicit on that point:
>
> Outside of comments, documentation and except in Kconfig,
> spaces are never used for indentation ...
I usually indent this way if expressions exceed the 80 columns limit:
if (foo___ &&
bar___) {
doit;
}
---
I disagree vigorously - the operators should be at the front of the
line, so that the logical structure is clear. [The editor I'm doing
this in won't let me use tabs, so I won't even try to do an
example...]
As other people have noted in this thread, it's a rule that would earn
Emerson's "foolish consistency" label, if it actually were followed
slavishly. In fact, the kernel looks like people tend to do the right
thing, rather than always following the letter of the law.
Tab indenting is a good rule for the general case, but there are also
places (and breaking long conditionals is at the top of the list)
where it's much more important to express the structure, and the
structure has too many logical sub-points to line up with the
relatively small number of 8-space tabs available in an 80-character
line.
Of course, expressions too complicated to fit the rule are also a sign
that you might want to simplify things...
scott
-
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/
Re: coding style for long conditions (WAS: Re: [PATCH 25/90] ... blinky leds!!)
On Friday 06 April 2007 18:57, David Brownell wrote: > On Friday 06 April 2007 3:17 pm, Thomas Gleixner wrote: > > David, > > > > http://tglx.de/private/tglx/usbnet.png > > > > /me recommends emacs-develock.el for colorful white space wreckage > > display ! > > Then I'd have to switch to EMACS ... no thanks! ;) Here is what I have in my .vimrc: highlight RedundantWhitespace ctermbg=red guibg=red match RedundantWhitespace /\s\+$\| \+\ze\t/ -- Dmitry - 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/
Re: coding style for long conditions (WAS: Re: [PATCH 25/90] ... blinky leds!!)
On Friday 06 April 2007 18:57, David Brownell wrote: On Friday 06 April 2007 3:17 pm, Thomas Gleixner wrote: David, http://tglx.de/private/tglx/usbnet.png /me recommends emacs-develock.el for colorful white space wreckage display ! Then I'd have to switch to EMACS ... no thanks! ;) Here is what I have in my .vimrc: highlight RedundantWhitespace ctermbg=red guibg=red match RedundantWhitespace /\s\+$\| \+\ze\t/ -- Dmitry - 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/
Re: coding style for long conditions (WAS: Re: [PATCH 25/90] ... blinky leds!!)
On 4/6/07, Stefan Richter [EMAIL PROTECTED] wrote:
David Brownell wrote:
[...]
1 if (To control chain reactions, your odds
2 Improve if you've got cadmium rods) {
3 In your fission reactor
4 Their lack is a factor
5 }
6 In screams of A meltdown! Ye gods!
Now, the former makes it hard to tell what's condition vs consequent.
(Or whatever the correct technical term is in cases like these.)
My fu dictates that continuation lines (line 2 in this example)
should have more indent than line 1,
Yes. Where indent is measured -- always!! -- in tabs.
Documentation/Coding style is quite explicit on that point:
Outside of comments, documentation and except in Kconfig,
spaces are never used for indentation ...
I usually indent this way if expressions exceed the 80 columns limit:
if (foo___
bar___) {
doit;
}
---
I disagree vigorously - the operators should be at the front of the
line, so that the logical structure is clear. [The editor I'm doing
this in won't let me use tabs, so I won't even try to do an
example...]
As other people have noted in this thread, it's a rule that would earn
Emerson's foolish consistency label, if it actually were followed
slavishly. In fact, the kernel looks like people tend to do the right
thing, rather than always following the letter of the law.
Tab indenting is a good rule for the general case, but there are also
places (and breaking long conditionals is at the top of the list)
where it's much more important to express the structure, and the
structure has too many logical sub-points to line up with the
relatively small number of 8-space tabs available in an 80-character
line.
Of course, expressions too complicated to fit the rule are also a sign
that you might want to simplify things...
scott
-
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/
Re: coding style for long conditions (WAS: Re: [PATCH 25/90] ... blinky leds!!)
Jan Engelhardt <[EMAIL PROTECTED]> writes: > Tabs should be used for indent, not padding. People wanting to use > different-sized tabs can change settings in their editor, i.e. > to make a tab 12 instead of 8. Or 6. Or whatever. If tabs only ever > appear at the front, this works, it breaks when tabs are used to line > up foo->bar=1; foo->boom=17; statements. Precisely. If someone really likes if (a && b) or if ( a && b ) then let be it (in his/her code), but please don't fight if (a && b) Just make sure only tabs are used for indent, i.e., the last is: \t*if (a && \t*\s\s\s\sb) another example: \t*if (condition1 && (a + \t* b)) ^^^ <<< spaces, not tabs I think the current CodingStyle is clear enough but improvements there aren't prohibited. -- Krzysztof Halasa - 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/
Re: coding style for long conditions (WAS: Re: [PATCH 25/90] ... blinky leds!!)
On Apr 6 2007 15:40, David Brownell wrote:
>> >if (...) {
>> >THAT WAS ONE MORE TAB
>> >}
>> >
>> >Come on, stop wasting everyone's time with utter nonsense.
>> I was never debating these two things.
>Actually, you did.
If it was perceived I did, then I owe you an apology.
>Go back and see the point I was specifically
>disagreeing with. It related to the body of the "if" block,
>which you had said would **NOT** indent by a single tab.
Ok somewhere is a bug. What is the body an if block, for you? To avoid
that confusion, I termed these "condition" and "code":
if(condition1 ||/* if() line */
condition2) { /* continuation line */
code; /* body */
code; /* body */
}
And I think I made that pretty clear in ,
which part is what, and how I like things.
In , the loop begins then.
Yes, it does not match "(a) only use tabs", but it matches the
rest of kernel code.
Jan
--
-
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/
Re: coding style for long conditions (WAS: Re: [PATCH 25/90] ... blinky leds!!)
On Friday 06 April 2007 4:21 pm, Thomas Gleixner wrote: > David, > > On Fri, 2007-04-06 at 15:57 -0700, David Brownell wrote: > > This particular issue doesn't actually affect indentation, since the > > tab trumps that space. So it's a bit off-agenda for this particular > > flamage. > > ROTFL, the tab trumps the space. Is this a card game ? Nah, just standard display algorithms. Alignment doesn't change. > > > Please change your coding style to conform to Documentation/CodingStyle. > > > > > > *** Only indent with tabs!! *** > > How does your own rule make SPACE-TAB-TAB more acceptable than > TAB-TAB-SPACE ? Just because TAB trumps the space but not the other way > round ? Because when you display the text, it doesn't affect the alignment == indentation. In fact you have to turn on nonstandard editor options to even see if this happened. Not everyone does so, which is why such things persist. So in practical terms "\n \t" and "\n\t" are identical; although the former "should not" be used, it doesn't actually affect what CodingStyle is primarily trying to control (i.e. what the code looks like). > You started nitpicking, so please accept the backfire. Done. :) - 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/
Re: coding style for long conditions (WAS: Re: [PATCH 25/90] ... blinky leds!!)
David, On Fri, 2007-04-06 at 15:57 -0700, David Brownell wrote: > This particular issue doesn't actually affect indentation, since the > tab trumps that space. So it's a bit off-agenda for this particular > flamage. ROTFL, the tab trumps the space. Is this a card game ? > > Please change your coding style to conform to Documentation/CodingStyle. > > > > *** Only indent with tabs!! *** How does your own rule make SPACE-TAB-TAB more acceptable than TAB-TAB-SPACE ? Just because TAB trumps the space but not the other way round ? You started nitpicking, so please accept the backfire. tglx P.S: Please remove me from CC. I regret already, that I dragged myself into this highly sophisticated and useful waste of electrons. I just had that file opened in my favorite editor while I was skimming through LKML. - 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/
Re: coding style for long conditions (WAS: Re: [PATCH 25/90] ... blinky leds!!)
On Friday 06 April 2007 3:17 pm, Thomas Gleixner wrote: > David, > > http://tglx.de/private/tglx/usbnet.png > > /me recommends emacs-develock.el for colorful white space wreckage > display ! Then I'd have to switch to EMACS ... no thanks! ;) At the risk of switching to a VI/EMACS flamewar (could that be an improvement?) "let c_space_errors=1" shows the same sort of thing ... albeit a bit more usefully, it just highlights the single useless space character at the beginning of that line. (Which starts "space-TAB-TAB-TAB".) > You probably want to look at more files contributed by david-b before > you look at mine :) I last touched that header in 2005 ... next time I have reason to touch it, I'll likely fix that little thing! Patches accepted. :) This particular issue doesn't actually affect indentation, since the tab trumps that space. So it's a bit off-agenda for this particular flamage. I tend to fix such space errors whenever I trip over them; e.g. "git show 438d6c2c015cf63bf7e9bdc2033d435433ac8455". - Dave - 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/
Re: coding style for long conditions (WAS: Re: [PATCH 25/90] ... blinky leds!!)
On Friday 06 April 2007 3:04 pm, Jan Engelhardt wrote:
> > if (...) {
> > THAT WAS ONE MORE TAB
> > }
> >
> >and
> >
> > for (...) {
> > THAT WAS ALSO ONE MORE TAB
> > }
> >
> >Come on, stop wasting everyone's time with utter nonsense.
>
> I was never debating these two things.
Actually, you did. Go back and see the point I was specifically
disagreeing with. It related to the body of the "if" block,
which you had said would **NOT** indent by a single tab.
-
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/
Re: coding style for long conditions (WAS: Re: [PATCH 25/90] ... blinky leds!!)
David, On Fri, 2007-04-06 at 14:05 -0700, David Brownell wrote: > Please change your coding style to conform to Documentation/CodingStyle. > > *** Only indent with tabs!! *** > > Every one of those examples violates that simple rule. > > Why does *anyone* have even the slightest difficulty understanding such a > simple rule? I realize that two of those words have more than a single > syllable, but that should not be a problem. Even EMACS is trainable. please stop to be more Catholic than the Pope. commit 0aa599c5644fddd3052433c5335260108a8a39a2 drivers/usb/net/usbnet.h http://tglx.de/private/tglx/usbnet.png /me recommends emacs-develock.el for colorful white space wreckage display ! You probably want to look at more files contributed by david-b before you look at mine :) tglx - 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/
Re: coding style for long conditions (WAS: Re: [PATCH 25/90] ... blinky leds!!)
Hello David,
On Apr 6 2007 13:57, David Brownell wrote:
>> though I do not speak for
>> them, seem to do it much the way I described, judging from the code they
>> wrote/write.
>
>Your eyes are broken then ...
Sorry? I could have simply told you to look into kernel/signal.c LINE
220 (that's in the recalc_sigpending_tsk() function), to see that
THERE IS code which uses /^\t+\x20/ to indent wrapped if continuation
lines:
fastcall void recalc_sigpending_tsk(struct task_struct *t)
{
if (t->signal->group_stop_count > 0 ||
(freezing(t)) ||
PENDING(>pending, >blocked) ||
PENDING(>signal->shared_pending, >blocked))
set_tsk_thread_flag(t, TIF_SIGPENDING);
else
clear_tsk_thread_flag(t, TIF_SIGPENDING);
}
And this is not the only function. But since I figured you would
anyway object despite what I say...
>or maybe you're focussing exclusively
>on code that violates the most basic coding guidelines like:
...I wrote that script that actually proves my point (minus script
bugs - errare est humanum) that \t+\x20 is PREDOMINANT in kernel
code. Whether that invalidates what CodingStyle says is another
debate (which at best Randy just decides and sends a patch for which
is then hopefully committed instantly).
> if (...) {
> THAT WAS ONE MORE TAB
> }
>
>and
>
> for (...) {
> THAT WAS ALSO ONE MORE TAB
> }
>
>Come on, stop wasting everyone's time with utter nonsense.
I was never debating these two things. I was, however, if you have
not noticed yet, about wrapped if lines:
if (foo ||
continuation_with_2_or_more_spaces)
code_with_1_tab;
and
if (foo ||
continuation_with_2_tabs)
code_with_1_tab;
The former is what kernel code does "**TODAY**".
Thank you.
Jan
--
-
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/
Re: coding style for long conditions (WAS: Re: [PATCH 25/90] ... blinky leds!!)
On Friday 06 April 2007 2:37 pm, Jeremy Fitzhardinge wrote: > David Brownell wrote: > > Please change your coding style to conform to Documentation/CodingStyle. > > > > *** Only indent with tabs!! *** > > > > Every one of those examples violates that simple rule. > > > > Spaces are used to indent all over the kernel; using a few spaces to pad > out some indentation into the proper place is accepted practice, Not universally. And I must say it feels wrong to be the target of even a single complaint about actually **FOLLOWING THAT RULE** ... > regardless of what CodingStyle says. - 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/
Re: coding style for long conditions (WAS: Re: [PATCH 25/90] ... blinky leds!!)
On Apr 6 2007 14:05, David Brownell wrote: > >Please change your coding style to conform to Documentation/CodingStyle. > > *** Only indent with tabs!! *** > >Every one of those examples violates that simple rule. > >Why does *anyone* have even the slightest difficulty understanding such a >simple rule? I realize that two of those words have more than a single >syllable, but that should not be a problem. Even EMACS is trainable. Tabs should be used for indent, not padding. People wanting to use different-sized tabs can change settings in their editor, i.e. to make a tab 12 instead of 8. Or 6. Or whatever. If tabs only ever appear at the front, this works, it breaks when tabs are used to line up foo->bar=1; foo->boom=17; statements. Jan -- - 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/
Re: coding style for long conditions (WAS: Re: [PATCH 25/90] ... blinky leds!!)
David Brownell wrote: > On Friday 06 April 2007 12:03 pm, Stefan Richter wrote: > >> I usually indent this way if expressions exceed the 80 columns limit: Or in other words: - When a new scope is opened, increase indentations by 8 characters. Use a tab for that. - When wrapping within an expression, start the new line at the same column at which the (sub-)expression started. - Deviations from the latter rule allowed if it increases readability. > Please change your coding style to conform to Documentation/CodingStyle. I won't change this anymore in any legacy code I write patches for. But I also won't stand in the way of anybody who happens to submit patches which strictly only... > *** Only indent with tabs!! *** ...indent with tabs and change legacy code whose maintainer I am. > Every one of those examples violates that simple rule. > > Why does *anyone* have even the slightest difficulty understanding such a > simple rule? /Does/ anybody have difficulties? ... >> PS: Everyone please try to avoid blowing CodingStyle up to a 200 pages >> document. Thanks. > > Better yet, try to stick to its guidelines rather than growing lots of > exceptions saying when your personal style says you ought to use spaces > instead of tabs for indents, etc What I said at the top of this posting has not been newly grown recently but has been common practice for many years. It's not my personal style. (Note, I'm not saying one style is better than the other, nor am I saying that only one style can be allowed, nor am I saying that it's fine to have several different styles.) -- Stefan Richter -=-=-=== -=-- --==- http://arcgraph.de/sr/ - 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/
Re: coding style for long conditions (WAS: Re: [PATCH 25/90] ... blinky leds!!)
David Brownell wrote:
On Friday 06 April 2007 12:03 pm, Stefan Richter wrote:
I usually indent this way if expressions exceed the 80 columns limit:
if (foo___ &&
bar___) {
doit;
}
and
if ((one___ ||
one_and_a_half) &&
two___) {
doit;
}
and
call(abc___,
def___);
and
static int definition(abc___,
def___)
{
...
Please change your coding style to conform to Documentation/CodingStyle.
*** Only indent with tabs!! ***
Every one of those examples violates that simple rule.
Why does *anyone* have even the slightest difficulty understanding such a
simple rule? I realize that two of those words have more than a single
syllable, but that should not be a problem. Even EMACS is trainable.
PS: Everyone please try to avoid blowing CodingStyle up to a 200 pages
document. Thanks.
Better yet, try to stick to its guidelines rather than growing lots of
exceptions saying when your personal style says you ought to use spaces
instead of tabs for indents, etc
Randy, next time you criticise coding style, please make sure that the
code in question actually violates the existing rules first ... this
thread has been way too much noise, given that the usage you criticized
was in full conformance with that document, and the proposed fixes were
in blatant violation ...
Yeah, well, I've already given up. But please try to understand,
David, that CodingStyle can have mistakes in it, just like some of
the kernel code does. And like I said earlier, it's just a set of
guidelines.
And I haven't seen any flamage here (referring to another posting).
--
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
-
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/
Re: coding style for long conditions (WAS: Re: [PATCH 25/90] ... blinky leds!!)
David Brownell wrote: > Please change your coding style to conform to Documentation/CodingStyle. > > *** Only indent with tabs!! *** > > Every one of those examples violates that simple rule. > Spaces are used to indent all over the kernel; using a few spaces to pad out some indentation into the proper place is accepted practice, regardless of what CodingStyle says. The most important rule probably needs to be explicitly added: Break any of these rules sooner than say anything outright barbarous.[1] Though the first para of CodingStyle is very clear that it is a set of guidelines rather than strict rules. J 1: http://www.k-1.com/Orwell/index.cgi/work/essays/language.html - 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/
Re: coding style for long conditions (WAS: Re: [PATCH 25/90] ... blinky leds!!)
On Friday 06 April 2007 12:16 pm, Jan Engelhardt wrote:
> >> and that the inner block code
> >> (lines 3 and 4) should have more indent than line 2.
> >
> >We disagree. The "inner" block should in all cases have one-tab indent.
>
> You disagree. "We", as in, the kernel coders,
... agree with what I said, since that's exactly what CodingStyle says,
and what essentially every line of kernel code does today. (There are
random spots of brokenness, but they get fixed over time.)
> though I do not speak for
> them, seem to do it much the way I described, judging from the code they
> wrote/write.
Your eyes are broken then ... or maybe you're focussing exclusively
on code that violates the most basic coding guidelines like:
if (...) {
THAT WAS ONE MORE TAB
}
and
for (...) {
THAT WAS ALSO ONE MORE TAB
}
Come on, stop wasting everyone's time with utter nonsense.
- Indent always uses tabs
- When breaking long lines (including long conditions)
* STILL indent with tabs
* ... and more than one, to be "substantially" more indented
That's what Documentation/CodingStyle says **TODAY** so stop with the flamage.
-
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/
Re: coding style for long conditions (WAS: Re: [PATCH 25/90] ... blinky leds!!)
On Friday 06 April 2007 12:03 pm, Stefan Richter wrote:
>
> I usually indent this way if expressions exceed the 80 columns limit:
>
> if (foo___ &&
> bar___) {
> doit;
> }
> and
> if ((one___ ||
>one_and_a_half) &&
> two___) {
> doit;
> }
> and
> call(abc___,
>def___);
> and
>
> static int definition(abc___,
> def___)
> {
> ...
Please change your coding style to conform to Documentation/CodingStyle.
*** Only indent with tabs!! ***
Every one of those examples violates that simple rule.
Why does *anyone* have even the slightest difficulty understanding such a
simple rule? I realize that two of those words have more than a single
syllable, but that should not be a problem. Even EMACS is trainable.
> PS: Everyone please try to avoid blowing CodingStyle up to a 200 pages
> document. Thanks.
Better yet, try to stick to its guidelines rather than growing lots of
exceptions saying when your personal style says you ought to use spaces
instead of tabs for indents, etc
Randy, next time you criticise coding style, please make sure that the
code in question actually violates the existing rules first ... this
thread has been way too much noise, given that the usage you criticized
was in full conformance with that document, and the proposed fixes were
in blatant violation ...
- Dave
-
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/
Re: coding style for long conditions (WAS: Re: [PATCH 25/90] ... blinky leds!!)
On Apr 6 2007 10:29, David Brownell wrote:
>> Using
>> /^\t+\x20{2,8}/ on continuation line(s) is perfect because it does
>> not cause either the continuation line(s) or the inner block code to
>> move too much to the right.
>
>No, that's a clear violation of CodingStyle on two separate points:
>(a) the "always use tabs" rule, (b) the "substantially more" rule.
>
>Note also that the notion of using spaces is for indents is clearly
>described there as "heresy" .. your fu needs review if not overhaul.
Well, I did not consider that "space" to be indent, as in:
if($previous_line_was_an_if)
($indent, $padding) = (/^(\t+)(\x20{2,})/);
I do not want to argue about that now, though.
>And CodingStyle says that line 2 should have "substantially more" indent...
>
>Think of it this way: when the condition becomes so complex that it
>no longer fits on one line, that block should never be re-indented.
>Only the condition needs to be reworked to fit into 80 columns.
If the condition becomes so complex that it's "too complex", it should
be split up into multiple ifs, or even functions,
>So not just "more" indent, but "substantially more". (Although one
>could quibble, this is "expression" not "statement". Don't quibble.)
>
>> and that the inner block code
>> (lines 3 and 4) should have more indent than line 2.
>
>We disagree. The "inner" block should in all cases have one-tab indent.
You disagree. "We", as in, the kernel coders, though I do not speak for
them, seem to do it much the way I described, judging from the code they
wrote/write.
Please see the referenced perl script [1] that heuristically tries to figure
out the number of space-continued (SC) vs. tab-continued (TC) lines (L)
following an if (IF) statement.
linux-2.6.21-rc6$ find . -type f -iname '*.[ch]' -print0 | \
xargs -0 cat | ./findcont
L:7227630 IF:352877 NOCONT:309465 SC:30395 TC:8689 ##
NOCONT: 87.7% SC:8.6% TC:2.5%
(Does not quite add up to 100%, but I'll let someone
else figure that out.)
Jan
[1] https://svn.ahn.hopto.org/hxtools/trunk/supp/findcont
-
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/
Re: coding style for long conditions (WAS: Re: [PATCH 25/90] ... blinky leds!!)
David Brownell wrote:
[...]
>>> 1 if (To control chain reactions, your odds
>>> 2 Improve if you've got cadmium rods) {
>>> 3 In your fission reactor
>>> 4 Their lack is a factor
>>> 5 }
>>> 6 In screams of "A meltdown! Ye gods!"
>>>
>>> Now, the former makes it hard to tell what's condition vs consequent.
>>> (Or whatever the correct technical term is in cases like these.)
>> My fu dictates that continuation lines (line 2 in this example)
>> should have more indent than line 1,
>
> Yes. Where "indent" is measured -- always!! -- in tabs.
> Documentation/Coding style is quite explicit on that point:
>
> Outside of comments, documentation and except in Kconfig,
> spaces are never used for indentation ...
I usually indent this way if expressions exceed the 80 columns limit:
if (foo___ &&
bar___) {
doit;
}
and
if ((one___ ||
one_and_a_half) &&
two___) {
doit;
}
and
call(abc___,
def___);
and
static int definition(abc___,
def___)
{
...
and I know I'm not the only one. Yes, this means I indent with tabs and
spaces --- if I wrap within expressions or within lists of function
arguments. Of course there are always leading tabs before spaces, never
leading spaces.
PS: Everyone please try to avoid blowing CodingStyle up to a 200 pages
document. Thanks.
--
Stefan Richter
-=-=-=== -=-- --==-
http://arcgraph.de/sr/
-
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/
Re: coding style for long conditions (WAS: Re: [PATCH 25/90] ... blinky leds!!)
David Brownell wrote:
[...]
1 if (To control chain reactions, your odds
2 Improve if you've got cadmium rods) {
3 In your fission reactor
4 Their lack is a factor
5 }
6 In screams of A meltdown! Ye gods!
Now, the former makes it hard to tell what's condition vs consequent.
(Or whatever the correct technical term is in cases like these.)
My fu dictates that continuation lines (line 2 in this example)
should have more indent than line 1,
Yes. Where indent is measured -- always!! -- in tabs.
Documentation/Coding style is quite explicit on that point:
Outside of comments, documentation and except in Kconfig,
spaces are never used for indentation ...
I usually indent this way if expressions exceed the 80 columns limit:
if (foo___
bar___) {
doit;
}
and
if ((one___ ||
one_and_a_half)
two___) {
doit;
}
and
call(abc___,
def___);
and
static int definition(abc___,
def___)
{
...
and I know I'm not the only one. Yes, this means I indent with tabs and
spaces --- if I wrap within expressions or within lists of function
arguments. Of course there are always leading tabs before spaces, never
leading spaces.
PS: Everyone please try to avoid blowing CodingStyle up to a 200 pages
document. Thanks.
--
Stefan Richter
-=-=-=== -=-- --==-
http://arcgraph.de/sr/
-
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/
Re: coding style for long conditions (WAS: Re: [PATCH 25/90] ... blinky leds!!)
On Apr 6 2007 10:29, David Brownell wrote:
Using
/^\t+\x20{2,8}/ on continuation line(s) is perfect because it does
not cause either the continuation line(s) or the inner block code to
move too much to the right.
No, that's a clear violation of CodingStyle on two separate points:
(a) the always use tabs rule, (b) the substantially more rule.
Note also that the notion of using spaces is for indents is clearly
described there as heresy .. your fu needs review if not overhaul.
Well, I did not consider that space to be indent, as in:
if($previous_line_was_an_if)
($indent, $padding) = (/^(\t+)(\x20{2,})/);
I do not want to argue about that now, though.
And CodingStyle says that line 2 should have substantially more indent...
Think of it this way: when the condition becomes so complex that it
no longer fits on one line, that block should never be re-indented.
Only the condition needs to be reworked to fit into 80 columns.
If the condition becomes so complex that it's too complex, it should
be split up into multiple ifs, or even functions,
So not just more indent, but substantially more. (Although one
could quibble, this is expression not statement. Don't quibble.)
and that the inner block code
(lines 3 and 4) should have more indent than line 2.
We disagree. The inner block should in all cases have one-tab indent.
You disagree. We, as in, the kernel coders, though I do not speak for
them, seem to do it much the way I described, judging from the code they
wrote/write.
Please see the referenced perl script [1] that heuristically tries to figure
out the number of space-continued (SC) vs. tab-continued (TC) lines (L)
following an if (IF) statement.
linux-2.6.21-rc6$ find . -type f -iname '*.[ch]' -print0 | \
xargs -0 cat | ./findcont
L:7227630 IF:352877 NOCONT:309465 SC:30395 TC:8689 ##
NOCONT: 87.7% SC:8.6% TC:2.5%
(Does not quite add up to 100%, but I'll let someone
else figure that out.)
Jan
[1] https://svn.ahn.hopto.org/hxtools/trunk/supp/findcont
-
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/
Re: coding style for long conditions (WAS: Re: [PATCH 25/90] ... blinky leds!!)
On Friday 06 April 2007 12:16 pm, Jan Engelhardt wrote:
and that the inner block code
(lines 3 and 4) should have more indent than line 2.
We disagree. The inner block should in all cases have one-tab indent.
You disagree. We, as in, the kernel coders,
... agree with what I said, since that's exactly what CodingStyle says,
and what essentially every line of kernel code does today. (There are
random spots of brokenness, but they get fixed over time.)
though I do not speak for
them, seem to do it much the way I described, judging from the code they
wrote/write.
Your eyes are broken then ... or maybe you're focussing exclusively
on code that violates the most basic coding guidelines like:
if (...) {
THAT WAS ONE MORE TAB
}
and
for (...) {
THAT WAS ALSO ONE MORE TAB
}
Come on, stop wasting everyone's time with utter nonsense.
- Indent always uses tabs
- When breaking long lines (including long conditions)
* STILL indent with tabs
* ... and more than one, to be substantially more indented
That's what Documentation/CodingStyle says **TODAY** so stop with the flamage.
-
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/
Re: coding style for long conditions (WAS: Re: [PATCH 25/90] ... blinky leds!!)
On Friday 06 April 2007 12:03 pm, Stefan Richter wrote:
I usually indent this way if expressions exceed the 80 columns limit:
if (foo___
bar___) {
doit;
}
and
if ((one___ ||
one_and_a_half)
two___) {
doit;
}
and
call(abc___,
def___);
and
static int definition(abc___,
def___)
{
...
Please change your coding style to conform to Documentation/CodingStyle.
*** Only indent with tabs!! ***
Every one of those examples violates that simple rule.
Why does *anyone* have even the slightest difficulty understanding such a
simple rule? I realize that two of those words have more than a single
syllable, but that should not be a problem. Even EMACS is trainable.
PS: Everyone please try to avoid blowing CodingStyle up to a 200 pages
document. Thanks.
Better yet, try to stick to its guidelines rather than growing lots of
exceptions saying when your personal style says you ought to use spaces
instead of tabs for indents, etc
Randy, next time you criticise coding style, please make sure that the
code in question actually violates the existing rules first ... this
thread has been way too much noise, given that the usage you criticized
was in full conformance with that document, and the proposed fixes were
in blatant violation ...
- Dave
-
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/
Re: coding style for long conditions (WAS: Re: [PATCH 25/90] ... blinky leds!!)
David Brownell wrote: Please change your coding style to conform to Documentation/CodingStyle. *** Only indent with tabs!! *** Every one of those examples violates that simple rule. Spaces are used to indent all over the kernel; using a few spaces to pad out some indentation into the proper place is accepted practice, regardless of what CodingStyle says. The most important rule probably needs to be explicitly added: Break any of these rules sooner than say anything outright barbarous.[1] Though the first para of CodingStyle is very clear that it is a set of guidelines rather than strict rules. J 1: http://www.k-1.com/Orwell/index.cgi/work/essays/language.html - 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/
Re: coding style for long conditions (WAS: Re: [PATCH 25/90] ... blinky leds!!)
David Brownell wrote:
On Friday 06 April 2007 12:03 pm, Stefan Richter wrote:
I usually indent this way if expressions exceed the 80 columns limit:
if (foo___
bar___) {
doit;
}
and
if ((one___ ||
one_and_a_half)
two___) {
doit;
}
and
call(abc___,
def___);
and
static int definition(abc___,
def___)
{
...
Please change your coding style to conform to Documentation/CodingStyle.
*** Only indent with tabs!! ***
Every one of those examples violates that simple rule.
Why does *anyone* have even the slightest difficulty understanding such a
simple rule? I realize that two of those words have more than a single
syllable, but that should not be a problem. Even EMACS is trainable.
PS: Everyone please try to avoid blowing CodingStyle up to a 200 pages
document. Thanks.
Better yet, try to stick to its guidelines rather than growing lots of
exceptions saying when your personal style says you ought to use spaces
instead of tabs for indents, etc
Randy, next time you criticise coding style, please make sure that the
code in question actually violates the existing rules first ... this
thread has been way too much noise, given that the usage you criticized
was in full conformance with that document, and the proposed fixes were
in blatant violation ...
Yeah, well, I've already given up. But please try to understand,
David, that CodingStyle can have mistakes in it, just like some of
the kernel code does. And like I said earlier, it's just a set of
guidelines.
And I haven't seen any flamage here (referring to another posting).
--
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
-
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/
Re: coding style for long conditions (WAS: Re: [PATCH 25/90] ... blinky leds!!)
David Brownell wrote: On Friday 06 April 2007 12:03 pm, Stefan Richter wrote: I usually indent this way if expressions exceed the 80 columns limit: Or in other words: - When a new scope is opened, increase indentations by 8 characters. Use a tab for that. - When wrapping within an expression, start the new line at the same column at which the (sub-)expression started. - Deviations from the latter rule allowed if it increases readability. Please change your coding style to conform to Documentation/CodingStyle. I won't change this anymore in any legacy code I write patches for. But I also won't stand in the way of anybody who happens to submit patches which strictly only... *** Only indent with tabs!! *** ...indent with tabs and change legacy code whose maintainer I am. Every one of those examples violates that simple rule. Why does *anyone* have even the slightest difficulty understanding such a simple rule? /Does/ anybody have difficulties? ... PS: Everyone please try to avoid blowing CodingStyle up to a 200 pages document. Thanks. Better yet, try to stick to its guidelines rather than growing lots of exceptions saying when your personal style says you ought to use spaces instead of tabs for indents, etc What I said at the top of this posting has not been newly grown recently but has been common practice for many years. It's not my personal style. (Note, I'm not saying one style is better than the other, nor am I saying that only one style can be allowed, nor am I saying that it's fine to have several different styles.) -- Stefan Richter -=-=-=== -=-- --==- http://arcgraph.de/sr/ - 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/
Re: coding style for long conditions (WAS: Re: [PATCH 25/90] ... blinky leds!!)
On Friday 06 April 2007 2:37 pm, Jeremy Fitzhardinge wrote: David Brownell wrote: Please change your coding style to conform to Documentation/CodingStyle. *** Only indent with tabs!! *** Every one of those examples violates that simple rule. Spaces are used to indent all over the kernel; using a few spaces to pad out some indentation into the proper place is accepted practice, Not universally. And I must say it feels wrong to be the target of even a single complaint about actually **FOLLOWING THAT RULE** ... regardless of what CodingStyle says. - 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/
Re: coding style for long conditions (WAS: Re: [PATCH 25/90] ... blinky leds!!)
On Apr 6 2007 14:05, David Brownell wrote: Please change your coding style to conform to Documentation/CodingStyle. *** Only indent with tabs!! *** Every one of those examples violates that simple rule. Why does *anyone* have even the slightest difficulty understanding such a simple rule? I realize that two of those words have more than a single syllable, but that should not be a problem. Even EMACS is trainable. Tabs should be used for indent, not padding. People wanting to use different-sized tabs can change settings in their editor, i.e. to make a tab 12 instead of 8. Or 6. Or whatever. If tabs only ever appear at the front, this works, it breaks when tabs are used to line up foo-bar=1; foo-boom=17; statements. Jan -- - 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/
Re: coding style for long conditions (WAS: Re: [PATCH 25/90] ... blinky leds!!)
Hello David,
On Apr 6 2007 13:57, David Brownell wrote:
though I do not speak for
them, seem to do it much the way I described, judging from the code they
wrote/write.
Your eyes are broken then ...
Sorry? I could have simply told you to look into kernel/signal.c LINE
220 (that's in the recalc_sigpending_tsk() function), to see that
THERE IS code which uses /^\t+\x20/ to indent wrapped if continuation
lines:
fastcall void recalc_sigpending_tsk(struct task_struct *t)
{
if (t-signal-group_stop_count 0 ||
(freezing(t)) ||
PENDING(t-pending, t-blocked) ||
PENDING(t-signal-shared_pending, t-blocked))
set_tsk_thread_flag(t, TIF_SIGPENDING);
else
clear_tsk_thread_flag(t, TIF_SIGPENDING);
}
And this is not the only function. But since I figured you would
anyway object despite what I say...
or maybe you're focussing exclusively
on code that violates the most basic coding guidelines like:
...I wrote that script that actually proves my point (minus script
bugs - errare est humanum) that \t+\x20 is PREDOMINANT in kernel
code. Whether that invalidates what CodingStyle says is another
debate (which at best Randy just decides and sends a patch for which
is then hopefully committed instantly).
if (...) {
THAT WAS ONE MORE TAB
}
and
for (...) {
THAT WAS ALSO ONE MORE TAB
}
Come on, stop wasting everyone's time with utter nonsense.
I was never debating these two things. I was, however, if you have
not noticed yet, about wrapped if lines:
if (foo ||
continuation_with_2_or_more_spaces)
code_with_1_tab;
and
if (foo ||
continuation_with_2_tabs)
code_with_1_tab;
The former is what kernel code does **TODAY**.
Thank you.
Jan
--
-
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/
Re: coding style for long conditions (WAS: Re: [PATCH 25/90] ... blinky leds!!)
David, On Fri, 2007-04-06 at 14:05 -0700, David Brownell wrote: Please change your coding style to conform to Documentation/CodingStyle. *** Only indent with tabs!! *** Every one of those examples violates that simple rule. Why does *anyone* have even the slightest difficulty understanding such a simple rule? I realize that two of those words have more than a single syllable, but that should not be a problem. Even EMACS is trainable. please stop to be more Catholic than the Pope. commit 0aa599c5644fddd3052433c5335260108a8a39a2 drivers/usb/net/usbnet.h http://tglx.de/private/tglx/usbnet.png /me recommends emacs-develock.el for colorful white space wreckage display ! You probably want to look at more files contributed by david-b before you look at mine :) tglx - 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/
Re: coding style for long conditions (WAS: Re: [PATCH 25/90] ... blinky leds!!)
On Friday 06 April 2007 3:04 pm, Jan Engelhardt wrote:
if (...) {
THAT WAS ONE MORE TAB
}
and
for (...) {
THAT WAS ALSO ONE MORE TAB
}
Come on, stop wasting everyone's time with utter nonsense.
I was never debating these two things.
Actually, you did. Go back and see the point I was specifically
disagreeing with. It related to the body of the if block,
which you had said would **NOT** indent by a single tab.
-
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/
Re: coding style for long conditions (WAS: Re: [PATCH 25/90] ... blinky leds!!)
On Friday 06 April 2007 3:17 pm, Thomas Gleixner wrote: David, http://tglx.de/private/tglx/usbnet.png /me recommends emacs-develock.el for colorful white space wreckage display ! Then I'd have to switch to EMACS ... no thanks! ;) At the risk of switching to a VI/EMACS flamewar (could that be an improvement?) let c_space_errors=1 shows the same sort of thing ... albeit a bit more usefully, it just highlights the single useless space character at the beginning of that line. (Which starts space-TAB-TAB-TAB.) You probably want to look at more files contributed by david-b before you look at mine :) I last touched that header in 2005 ... next time I have reason to touch it, I'll likely fix that little thing! Patches accepted. :) This particular issue doesn't actually affect indentation, since the tab trumps that space. So it's a bit off-agenda for this particular flamage. I tend to fix such space errors whenever I trip over them; e.g. git show 438d6c2c015cf63bf7e9bdc2033d435433ac8455. - Dave - 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/
Re: coding style for long conditions (WAS: Re: [PATCH 25/90] ... blinky leds!!)
David, On Fri, 2007-04-06 at 15:57 -0700, David Brownell wrote: This particular issue doesn't actually affect indentation, since the tab trumps that space. So it's a bit off-agenda for this particular flamage. ROTFL, the tab trumps the space. Is this a card game ? Please change your coding style to conform to Documentation/CodingStyle. *** Only indent with tabs!! *** How does your own rule make SPACE-TAB-TAB more acceptable than TAB-TAB-SPACE ? Just because TAB trumps the space but not the other way round ? You started nitpicking, so please accept the backfire. tglx P.S: Please remove me from CC. I regret already, that I dragged myself into this highly sophisticated and useful waste of electrons. I just had that file opened in my favorite editor while I was skimming through LKML. - 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/
Re: coding style for long conditions (WAS: Re: [PATCH 25/90] ... blinky leds!!)
On Friday 06 April 2007 4:21 pm, Thomas Gleixner wrote: David, On Fri, 2007-04-06 at 15:57 -0700, David Brownell wrote: This particular issue doesn't actually affect indentation, since the tab trumps that space. So it's a bit off-agenda for this particular flamage. ROTFL, the tab trumps the space. Is this a card game ? Nah, just standard display algorithms. Alignment doesn't change. Please change your coding style to conform to Documentation/CodingStyle. *** Only indent with tabs!! *** How does your own rule make SPACE-TAB-TAB more acceptable than TAB-TAB-SPACE ? Just because TAB trumps the space but not the other way round ? Because when you display the text, it doesn't affect the alignment == indentation. In fact you have to turn on nonstandard editor options to even see if this happened. Not everyone does so, which is why such things persist. So in practical terms \n \t and \n\t are identical; although the former should not be used, it doesn't actually affect what CodingStyle is primarily trying to control (i.e. what the code looks like). You started nitpicking, so please accept the backfire. Done. :) - 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/
Re: coding style for long conditions (WAS: Re: [PATCH 25/90] ... blinky leds!!)
On Apr 6 2007 15:40, David Brownell wrote:
if (...) {
THAT WAS ONE MORE TAB
}
Come on, stop wasting everyone's time with utter nonsense.
I was never debating these two things.
Actually, you did.
If it was perceived I did, then I owe you an apology.
Go back and see the point I was specifically
disagreeing with. It related to the body of the if block,
which you had said would **NOT** indent by a single tab.
Ok somewhere is a bug. What is the body an if block, for you? To avoid
that confusion, I termed these condition and code:
if(condition1 ||/* if() line */
condition2) { /* continuation line */
code; /* body */
code; /* body */
}
And I think I made that pretty clear in http://lkml.org/lkml/2007/4/5/293,
which part is what, and how I like things.
In http://lkml.org/lkml/2007/4/6/133, the loop begins then.
Yes, it does not match (a) only use tabs, but it matches the
rest of kernel code.
Jan
--
-
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/
Re: coding style for long conditions (WAS: Re: [PATCH 25/90] ... blinky leds!!)
Jan Engelhardt [EMAIL PROTECTED] writes: Tabs should be used for indent, not padding. People wanting to use different-sized tabs can change settings in their editor, i.e. to make a tab 12 instead of 8. Or 6. Or whatever. If tabs only ever appear at the front, this works, it breaks when tabs are used to line up foo-bar=1; foo-boom=17; statements. Precisely. If someone really likes if (a b) or if ( a b ) then let be it (in his/her code), but please don't fight if (a b) Just make sure only tabs are used for indent, i.e., the last is: \t*if (a \t*\s\s\s\sb) another example: \t*if (condition1 (a + \t* b)) ^^^ spaces, not tabs I think the current CodingStyle is clear enough but improvements there aren't prohibited. -- Krzysztof Halasa - 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/
