linux-kernel - coding style for long conditions (WAS: Re: [PATCH 25/90] ... blinky leds!!)

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]

Message-Id: <200704061029.55710.david-b@pacbell.net>
Date:	Fri, 6 Apr 2007 10:29:55 -0700
From:	David Brownell <david-b@...bell.net>
To:	Jan Engelhardt <jengelh@...ux01.gwdg.de>
Cc:	Randy Dunlap <randy.dunlap@...cle.com>,
	Tony Lindgren <tony@...mide.com>, linux-kernel@...r.kernel.org,
	David Brownell <dbrownell@...rs.sourceforge.net>
Subject: coding style for long conditions (WAS: Re: [PATCH 25/90] ... blinky leds!!)

On Thursday 05 April 2007 1:35 pm, Jan Engelhardt wrote:
>
> >obeys the only-ident-by-tabs rule, as does
> >
> >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 ...

Note also:

	Statements longer than 80 columns will be broken into sensible
	chunks.   Descendants are always substantially shorter than the
	parent and are placed substantially to the right. The same applies
	to function headers with a long argument list. Long strings are
	as well broken into shorter strings.

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.

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.

The entire point of "substantially more" is to stand out from the normal
"indent by one tab" rule" ... so that it's not mistaken for anything
except a line-wrap reformat.

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

- Dave

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