linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jean Delvare <jdelvare@suse.de>
To: Joe Perches <joe@perches.com>
Cc: Julia Lawall <julia.lawall@lip6.fr>,
	Al Viro <viro@ZenIV.linux.org.uk>,
	Ilya Dryomov <idryomov@gmail.com>,
	Andy Whitcroft <apw@canonical.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Jonathan Corbet <corbet@lwn.net>,
	Ceph Development <ceph-devel@vger.kernel.org>,
	Alex Elder <elder@kernel.org>, Sage Weil <sage@redhat.com>,
	LKML <linux-kernel@vger.kernel.org>,
	kernel-janitors@vger.kernel.org,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-doc@vger.kernel.org
Subject: Re: "CodingStyle: Clarify and complete chapter 7" in docs-next
Date: Thu, 22 Sep 2016 13:57:58 +0200	[thread overview]
Message-ID: <20160922135758.0399725d@endymion> (raw)
In-Reply-To: <1474540930.8253.9.camel@perches.com>

On Thu, 22 Sep 2016 03:42:10 -0700, Joe Perches wrote:
> On Thu, 2016-09-22 at 11:24 +0200, Jean Delvare wrote:
> > I would rather suggest:
> > 
> > ERROR -> MUST_FIX
> > WARNING -> SHOULD_FIX
> > CHECK -> MAY_FIX
> 
> MUST is much stronger language than I would prefer.

That's what error means, really. When your compiler fails with an
error, you have no choice but to fix your code. Warnings on the other
hand may be ignored sometimes.

> There are still about a quarter million ERRORs just for
> spacing issues in the kernel tree.
> 
> Here are the top 10 ERROR checkpatch messages treewide as of
> a few days ago,
> 
> $ grep ERROR checkpatch.short_sorted_20160917
>  268308  ERROR:SPACING
>   37340  ERROR:CODE_INDENT
>   27678  ERROR:TRAILING_WHITESPACE
>   21024  ERROR:COMPLEX_MACRO
>   14048  ERROR:POINTER_LOCATION
>   12207  ERROR:TRAILING_STATEMENTS
>   11079  ERROR:OPEN_BRACE
>    6802  ERROR:ASSIGN_IN_IF
>    3940  ERROR:RETURN_PARENTHESES
>    2322  ERROR:NON_OCTAL_PERMISSIONS
> 
> Maybe there could be some better classifications of the various
> messages.
> 
> But there are about two million checkpatch messages overall in
> the kernel tree.
> 
> That's a lot.

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.

checkpatch was called checkPATCH for a reason. It's main intent was to
prevent NEW (coding-style mostly) errors from creeping into the kernel.
The fact that old code does now always follow these recommendations is
unfortunate but that doesn't make checkpatch wrong or bad.

ERROR means that the new code isn't allowed to do that. Period.

-- 
Jean Delvare
SUSE L3 Support

  reply	other threads:[~2016-09-22 11:58 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-19 11:53 "CodingStyle: Clarify and complete chapter 7" in docs-next (was Re: [PATCH 03/47] block-rbd: Adjust the position of a jump label in rbd_header_from_disk()) Ilya Dryomov
2016-09-20  0:11 ` Al Viro
2016-09-20  2:46   ` Joe Perches
2016-09-20  5:53     ` Julia Lawall
2016-09-20  6:32       ` Joe Perches
2016-09-20  6:46         ` Julia Lawall
2016-09-22  9:24         ` "CodingStyle: Clarify and complete chapter 7" in docs-next Jean Delvare
2016-09-22 10:42           ` Joe Perches
2016-09-22 11:57             ` Jean Delvare [this message]
2016-09-22 13:11               ` Al Viro
2016-09-22 14:58                 ` Jean Delvare
2016-09-22 15:05                   ` Julia Lawall
2016-09-22 17:50                 ` Joe Perches
2016-09-22 17:49               ` Joe Perches
2016-09-22 19:47                 ` Jean Delvare
2016-09-22 10:43           ` Jani Nikula
2016-09-22 12:46             ` Jean Delvare
2016-09-22 13:06               ` Jani Nikula

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160922135758.0399725d@endymion \
    --to=jdelvare@suse.de \
    --cc=akpm@linux-foundation.org \
    --cc=apw@canonical.com \
    --cc=ceph-devel@vger.kernel.org \
    --cc=corbet@lwn.net \
    --cc=elder@kernel.org \
    --cc=idryomov@gmail.com \
    --cc=joe@perches.com \
    --cc=julia.lawall@lip6.fr \
    --cc=kernel-janitors@vger.kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sage@redhat.com \
    --cc=torvalds@linux-foundation.org \
    --cc=viro@ZenIV.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).