From mboxrd@z Thu Jan 1 00:00:00 1970 From: Joe Perches Subject: Re: "CodingStyle: Clarify and complete chapter 7" in docs-next Date: Thu, 22 Sep 2016 10:49:47 -0700 Message-ID: <1474566587.8253.14.camel@perches.com> References: <20160920001159.GM2356@ZenIV.linux.org.uk> <1474339566.1954.25.camel@perches.com> <1474353123.1954.28.camel@perches.com> <20160922112407.47da9393@endymion> <1474540930.8253.9.camel@perches.com> <20160922135758.0399725d@endymion> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit Return-path: In-Reply-To: <20160922135758.0399725d@endymion> Sender: linux-kernel-owner@vger.kernel.org To: Jean Delvare Cc: Julia Lawall , Al Viro , Ilya Dryomov , Andy Whitcroft , Linus Torvalds , Jonathan Corbet , Ceph Development , Alex Elder , Sage Weil , LKML , kernel-janitors@vger.kernel.org, Andrew Morton , linux-doc@vger.kernel.org List-Id: ceph-devel.vger.kernel.org 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. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Joe Perches Date: Thu, 22 Sep 2016 17:49:47 +0000 Subject: Re: "CodingStyle: Clarify and complete chapter 7" in docs-next Message-Id: <1474566587.8253.14.camel@perches.com> List-Id: References: <20160920001159.GM2356@ZenIV.linux.org.uk> <1474339566.1954.25.camel@perches.com> <1474353123.1954.28.camel@perches.com> <20160922112407.47da9393@endymion> <1474540930.8253.9.camel@perches.com> <20160922135758.0399725d@endymion> In-Reply-To: <20160922135758.0399725d@endymion> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable To: Jean Delvare Cc: Julia Lawall , Al Viro , Ilya Dryomov , Andy Whitcroft , Linus Torvalds , Jonathan Corbet , Ceph Development , Alex Elder , Sage Weil , LKML , kernel-janitors@vger.kernel.org, Andrew Morton , linux-doc@vger.kernel.org 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? =A0Are 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. -- To unsubscribe from this list: send the line "unsubscribe kernel-janitors" = in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html