From: Mauro Carvalho Chehab <mchehab@infradead.org>
To: Joe Perches <joe@perches.com>
Cc: Josh Triplett <josh@joshtriplett.org>,
linux-kernel@vger.kernel.org, Andy Whitcroft <apw@canonical.com>,
Linus Torvalds <torvalds@linux-foundation.org>,
ksummit-2013-discuss@lists.linuxfoundation.org,
David Howells <dhowells@redhat.com>
Subject: Re: [Ksummit-2013-discuss] [PATCH] checkpatch: Add comment about updating Documentation/CodingStyle
Date: Mon, 2 Sep 2013 16:48:24 -0300 [thread overview]
Message-ID: <20130902164824.76da7032@infradead.org> (raw)
In-Reply-To: <1378148367.1953.98.camel@joe-AO722>
Em Mon, 02 Sep 2013 11:59:27 -0700
Joe Perches <joe@perches.com> escreveu:
> On Mon, 2013-09-02 at 15:39 -0300, Mauro Carvalho Chehab wrote:
> > Em Mon, 2 Sep 2013 11:19:01 -0700
> > Josh Triplett <josh@joshtriplett.org> escreveu:
> []
> > > +# This file does not define the kernel coding style; Documentation/CodingStyle
> > > +# does. If you add a new style test to this file, add the corresponding style
> > > +# rule it enforces to Documentation/CodingStyle.
>
> > Agreed with that.
>
> I do not.
>
> > I would also add another comment there: "in case of
> > conflicts between checkpatch.pl and Documentation/CodingStyle, the latter
> > takes precedence."
>
> There are many checkpatch rules (like semicolons) that
> are not in CodingStyle.
Well, document them there, please.
> CodingStyle should not become some intensely detailed
> document that specifies the "only one true way" to
> write code.
There will always be things that will be freed to the programmer to
use, but CodingStyle should reflect what is the coding style we're
adopting at the Kernel, or putting it on another way: what things
will make the patch to be rejected because of its style.
> I also think checkpatch should not be used by robots
> to determine that patches are bad or unacceptable.
>
> checkpatch is just a dumb little tool that has some
> utility but as Dan Carpenter once said, "it's less
> sentient than a squirrel".
>
> People should always use their own taste before
> relying on dumb tools.
That's easier said than done. There are lots of stupid changes that are
done by developers (like enforcing 80 cols whitespace breaks) just
because of the checkpatch warnings. That happens before those patches
got sent to the ML's, as most people know that maintainers will curse
them if the coding style is crap[1].
[1] BTW, most of the time that checkpatch complains, the code is
really crap.
In any case, Documentation/CodingStyle is the reference document that
maintainers and coders should use to know that a code is following the
style (and not checkpatch). So, it requires updates when new
CodingStyle enforcements are created.
In the specific example pointed by David, if "extern", will start
to become a bad word that should be avoided, that should be documented
there at CodingStyle, and checkpatch should just be the dumb monkey
that will check that.
Cheers,
Mauro
next prev parent reply other threads:[~2013-09-02 19:48 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <9976.1378132260@warthog.procyon.org.uk>
2013-09-02 16:10 ` Making changes to the Coding Style Joe Perches
2013-09-02 18:15 ` [Ksummit-2013-discuss] " Josh Triplett
2013-09-02 18:19 ` [PATCH] checkpatch: Add comment about updating Documentation/CodingStyle Josh Triplett
2013-09-02 18:39 ` [Ksummit-2013-discuss] " Mauro Carvalho Chehab
2013-09-02 18:59 ` Joe Perches
2013-09-02 19:48 ` Mauro Carvalho Chehab [this message]
2013-09-02 19:50 ` Josh Triplett
2013-09-02 20:04 ` Guenter Roeck
2013-09-02 22:14 ` [PATCH] checkpatch: Report missing spaces around trigraphs with --strict Joe Perches
2013-09-02 23:15 ` Josh Triplett
2013-09-02 23:54 ` Joe Perches
2013-09-03 0:32 ` Josh Triplett
2013-09-02 20:50 ` [Ksummit-2013-discuss] [PATCH] checkpatch: Add comment about updating Documentation/CodingStyle David Howells
2013-09-02 21:11 ` Joe Perches
2013-09-03 0:26 ` Shilong Wang
2013-09-03 0:36 ` Josh Triplett
2013-09-03 1:21 ` Fengguang Wu
2013-09-03 0:39 ` Fengguang Wu
2013-09-03 0:47 ` Joe Perches
2013-09-03 1:35 ` Fengguang Wu
2013-09-03 1:34 ` Josh Triplett
2013-09-03 1:52 ` Joe Perches
2013-09-03 2:12 ` Josh Triplett
2013-09-03 2:21 ` Joe Perches
2013-09-03 2:46 ` Fengguang Wu
2013-09-03 3:16 ` Josh Triplett
2013-09-03 3:22 ` Fengguang Wu
2013-09-03 18:09 ` Bjorn Helgaas
2013-09-04 0:49 ` Fengguang Wu
2013-09-02 22:08 ` Josh Triplett
2013-09-02 19:34 ` Josh Triplett
2013-09-02 19:40 ` [PATCH] checkpatch: Add warning about submitting patches using --file Joe Perches
2013-09-02 19:54 ` [Ksummit-2013-discuss] " Mauro Carvalho Chehab
2013-09-02 19:56 ` Josh Triplett
2013-09-02 20:37 ` Dan Carpenter
2013-09-02 21:51 ` Joe Perches
2013-09-17 21:33 ` Andrew Morton
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=20130902164824.76da7032@infradead.org \
--to=mchehab@infradead.org \
--cc=apw@canonical.com \
--cc=dhowells@redhat.com \
--cc=joe@perches.com \
--cc=josh@joshtriplett.org \
--cc=ksummit-2013-discuss@lists.linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
/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