lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Fri, 6 Apr 2007 21:16:00 +0200 (MEST)
From:	Jan Engelhardt <jengelh@...ux01.gwdg.de>
To:	David Brownell <david-b@...bell.net>
cc:	Randy Dunlap <randy.dunlap@...cle.com>,
	Tony Lindgren <tony@...mide.com>, linux-kernel@...r.kernel.org,
	David Brownell <dbrownell@...rs.sourceforge.net>
Subject: 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 majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ