[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1474566587.8253.14.camel@perches.com>
Date: Thu, 22 Sep 2016 10:49:47 -0700
From: Joe Perches <joe@...ches.com>
To: Jean Delvare <jdelvare@...e.de>
Cc: Julia Lawall <julia.lawall@...6.fr>,
Al Viro <viro@...IV.linux.org.uk>,
Ilya Dryomov <idryomov@...il.com>,
Andy Whitcroft <apw@...onical.com>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Jonathan Corbet <corbet@....net>,
Ceph Development <ceph-devel@...r.kernel.org>,
Alex Elder <elder@...nel.org>, Sage Weil <sage@...hat.com>,
LKML <linux-kernel@...r.kernel.org>,
kernel-janitors@...r.kernel.org,
Andrew Morton <akpm@...ux-foundation.org>,
linux-doc@...r.kernel.org
Subject: Re: "CodingStyle: Clarify and complete chapter 7" in docs-next
On Thu, 2016-09-22 at 13:57 +0200, Jean Delvare wrote:
> Sure. But I'm afraid you keep changing topics and I have no idea where
> you are going. We started with "should there be a space before jump
> labels", then out of nowhere we were discussing the wording of the
> output of checkpatch (how is that related?) and now you pull statistics
> out of your hat, like these numbers imply anything.
No, not out of a hat. Those are the results of a silly script that
runs checkpatch on every .[ch] kernel file (but not tools/) with:
--show-types --terse --emacs --strict --no-summary --quiet -f
The magnitude of "ERRORS" is high and it's not necessary or useful
to modify old or obsolete code just to reduce that magnitude.
> checkpatch was called checkPATCH for a reason.
That's why I promote the --force option to limit using checkpatch on
files outside of staging.
https://patchwork.kernel.org/patch/9332205/
Andrew? Are you going to apply that one day?
> ERROR means that the new code isn't allowed to do that. Period.
Disagree. The compiler doesn't care. The value of consistency in
reducing defects is very hard to quantify.
Powered by blists - more mailing lists