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/
