From: Ingo Molnar <mingo@elte.hu>
To: Andy Whitcroft <apw@shadowen.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Randy Dunlap <rdunlap@xenotime.net>,
Joel Schopp <jschopp@austin.ibm.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] update checkpatch.pl to version 0.10
Date: Fri, 28 Sep 2007 11:39:02 +0200 [thread overview]
Message-ID: <20070928093902.GA28455@elte.hu> (raw)
In-Reply-To: <20070928092235.GA31180@shadowen.org>
* Andy Whitcroft <apw@shadowen.org> wrote:
> > > WARNING: multiple assignments should be avoided
> > > #2319:
> > > + max_load = this_load = total_load = total_pwr = 0;
> >
> > That warning is non-bogus, although this is one of the bogosities
> > which I personally don't bother fixing or making a fuss about.
> >
> > But I do think it detracts from the readability of the code, and
> > from patches which later alter that code. A bit.
>
> I tend to agree, watching the automatic replies from checkpatch, the
> majority of these are "justifiable" in their context. I think I'll
> lower this one to a CHECK in the next release.
what matters is that only items should be displayed that i _can_ fix.
With v8 i was able to make kernel/sched*.c almost noise-free, but with
v9 and v10 that's not possible anymore. And the moment the default
output of the tool cannot be made 'empty', we've lost the biggest
battle. Seeing the same bogus (or borderline) warnings again and again
destroys the biggest dynamic that could get people to use this tool more
often: the gratification of having a 'perfectly clean' file/patch.
And this is not about any particular false positive. I dont mind an
"advanced mode" non-default opt-in option for the script, if someone is
interested in borderline or hard to judge warnings too, but these
default false positives are _lethal_ for a tool like this. (and i made
this point before.) This is a _fundamental_ thing, and i'm still not
sure whether you accept and understand that point. This is very basic
and very important, and this isnt the first (or second) time i raised
this.
Ingo
next prev parent reply other threads:[~2007-09-28 9:39 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-09-12 15:00 [PATCH] update checkpatch.pl to version 0.10 Andy Whitcroft
2007-09-28 8:40 ` Ingo Molnar
2007-09-28 9:01 ` Andrew Morton
2007-09-28 9:22 ` Andy Whitcroft
2007-09-28 9:39 ` Ingo Molnar [this message]
2007-09-28 10:00 ` Andy Whitcroft
2007-09-28 10:46 ` Christian Borntraeger
2007-09-28 11:03 ` WANG Cong
2007-09-28 14:19 ` Jan Engelhardt
2007-09-28 16:57 ` Randy Dunlap
2007-09-28 10:49 ` Ingo Molnar
2007-09-28 13:21 ` Andy Whitcroft
2007-09-28 13:37 ` Pekka Enberg
2007-09-28 14:02 ` Andy Whitcroft
2007-09-28 15:50 ` Joel Schopp
2007-09-28 17:26 ` Randy Dunlap
2007-09-28 17:46 ` Andrew Morton
2007-09-29 9:22 ` Andy Whitcroft
2007-10-05 5:56 ` Ingo Molnar
2007-09-28 16:51 ` Sam Ravnborg
2007-09-28 9:44 ` Ingo Molnar
2007-09-28 9:52 ` Andy Whitcroft
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=20070928093902.GA28455@elte.hu \
--to=mingo@elte.hu \
--cc=akpm@linux-foundation.org \
--cc=apw@shadowen.org \
--cc=jschopp@austin.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=rdunlap@xenotime.net \
/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