linux-kernel - Re: [patch] checkpatch: relax spacing and line length

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: <47FCF6AF.8010703@panasas.com>
Date:	Wed, 09 Apr 2008 20:02:39 +0300
From:	Benny Halevy <bhalevy@...asas.com>
To:	Andy Whitcroft <apw@...dowen.org>
CC:	Jan Engelhardt <jengelh@...putergmbh.de>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	SL Baur <steve@...acs.org>,
	Randy Dunlap <rdunlap@...otime.net>,
	Richard Knutsson <ricknu-0@...dent.ltu.se>,
	Stefan Richter <stefanr@...6.in-berlin.de>
Subject: Re: [patch] checkpatch: relax spacing and line length

On Apr. 09, 2008, 16:25 +0300, Andy Whitcroft <apw@...dowen.org> wrote:
> On Wed, Apr 09, 2008 at 03:19:36PM +0300, Benny Halevy wrote:
>> On Apr. 08, 2008, 20:12 +0300, Andy Whitcroft <apw@...dowen.org> wrote:
>>> To justify changing checkpatch to loosen its checks I would hope to see
>>> an agreed to change to the CodingStyle detailing actually what is now
>>> acceptable.
>> For reference, here's Jan's proposal for Documentation/CodingStyle:
>> http://lkml.org/lkml/2008/2/26/462
> 
> Yes, seems reasonably well worded.  However, I see no consensus for its
> acceptance as a change.  I seem some near NAK's.

but no definite one :)
> 
> -apw

Seriously, I'm not sure how significant or relevant they are though.

In http://lkml.org/lkml/2008/2/26/533,
SL Baur <steve <at> xemacs.org> said:
> The proposed two space change is ugly.  Can someone NAK it?

I'm not sure what "two space change" proposal this Steve referred to
and his rejection is based on not-to-sound aesthetic grounds.

The motivation behind our proposal is more than just aesthetic.
I believe that using tabs for indent and then spaces for alignment
is functionally better, works for everybody, and will eventually result
in a more readable code over time, hopefully leading to fewer bugs.

Randy's answer, http://lkml.org/lkml/2008/2/27/7
says he won't NAK it since:
> I would gladly NAK it, but most recent email from Linus about
> coding style is that we are getting too detailed about it,
> so unless there is some overwhelming need to change anything in
> CodingStyle, I'm for no changes (or maybe even some removals).

My interpretation of that is the the current CodingStyle is too detailed
*now* therefore we need to relax it, not keep it the way it is.
It's true, that we add more details to relax the requirements but
overall we'd allow for more flexibility.  To do that with removing
details rather than adding any is dangerous IMO since it can easily
lead to indentation chaos that makes everybody's life harder...

Richard Knutsson, in http://lkml.org/lkml/2008/2/28/356
adds an excellent point about needing smaller tab expansion
for narrow screens.

Stefan Richter in http://lkml.org/lkml/2008/2/26/523 commented:
> Jan Engelhardt, Benny Halevy, and Richard Knutsson wrote:
> > -Tabs are 8 characters, and thus indentations are also 8 characters.
> > -There are heretic movements that try to make indentations 4 (or even 2!)
> > -characters deep, and that is akin to trying to define the value of PI to
> > -be 3.
> 
> Don't do this

Again, I see no real reasons why not to besides being against Stefan's
preferences.  I repeat my point that the proposed style does not
necessarily encourage smaller tab expansion, it just makes it possible.

Well, enough said.
Back to fixin' bugs...

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