From: Detlev Zundel <dzu@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] Policy for checkpatch usage?
Date: Wed, 27 Apr 2011 11:07:32 +0200 [thread overview]
Message-ID: <m2vcy0cbaj.fsf@ohwell.denx.de> (raw)
In-Reply-To: <1303572578.3628.23.camel@ws-apr.office.loc> (Andreas Pretzsch's message of "Sat, 23 Apr 2011 17:29:38 +0200")
Hi Andreas,
> Am Donnerstag, den 21.04.2011, 17:46 +0200 schrieb Detlev Zundel:
>> Thanks for the input. Current base for discussion:
>>
>> Checkpatch is a tool that can help you find some style problems, but
>> is imperfect, and the things it complains about are of varying
>> importance. So use common sense in interpreting the results.
>>
>> Warnings that clearly only make sense in the Linux kernel can be
>> ignored. This includes "Use #include <linux/$file> instead of
>> <asm/$file>" for example.
>>
>> If you encounter warnings for existing code, not modified by your
>> patch, consider submitting a separate, cosmetic-only patch -- clearly
>> described as such -- that *precedes* your substantive patch.
>
> For minor modifications (e.g. changed arguments of a function call),
> adhere to the present codingstyle of the module. Relating checkpatch
> warnings can be ignored in this case. A respective note in the commit or
> cover letter why they are ignored is desired.
>
>
>> Anyone unhappy with that? Will this help newcomers?
>
> Sounds sensible to me. The extra paragraph above is to circumvent
> intermixing codingstyle inside a file. For example in common/main.c,
> there are "function (arg, arg)" all around. Not checkpatch compliant
> (and ugly, IMHO). Now when I modify one of this calls, e.g add an
> argument, I'd have to change this. Which leads to a mixture of styles in
> the file, which is even worse than than adhering to the "broken" style.
Thanks, I've updated the wiki page accordingly[1].
> In general, I'd suggest a - maybe informal - policy that while
> codingstyle is important, there are more relevant aspects like elegant
> code, sensible interfaces, proper use of static and const and so on.
> I'm sure any developer is willing to debate about these issues, but most
> volunteers (esp. company or freelance coders) will resign after the 3rd
> round of whitespace ping-pong...
I fully agree, but on the other hand if we do have a Codingstyle
document _and_ a tool to check for it, there should be no more than one
round and even this one round should only be neccessary if the poster
didn't previously read the Codingstyle document ;)
> Not sure how to phrase that without contradicting the basic idea, maybe
> with an additional paragraph like:
> "New modules have to be as checkpatch compliant as possible. Violations
> have to be justified in the commit or cover letter."
Let's skip this. My experience is that people want clear and sharp-cut
policies so that they can decide for themselves _before_ posting whether
they adhere to them. If we cannot achieve such a strictness in our
forumlation, I expect such clauses to generate more discussion than they
solve.
Thanks everyone for the input!
Detlev
[1] http://www.denx.de/wiki/U-Boot/Patches
--
System going down at 1:45 this afternoon for disk crashing.
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu at denx.de
next prev parent reply other threads:[~2011-04-27 9:07 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-04-20 9:24 [U-Boot] Policy for checkpatch usage? Detlev Zundel
2011-04-20 10:15 ` Graeme Russ
2011-04-20 12:43 ` Graeme Russ
2011-04-20 13:40 ` Detlev Zundel
2011-04-20 13:38 ` Detlev Zundel
2011-04-20 16:51 ` Scott Wood
2011-04-21 0:09 ` Graeme Russ
2011-04-21 5:18 ` Wolfgang Denk
2011-04-21 14:24 ` Detlev Zundel
2011-04-21 14:29 ` Detlev Zundel
2011-04-21 14:49 ` Eric Cooper
2011-04-21 14:56 ` Fabian Cenedese
2011-04-21 15:04 ` Eric Cooper
2011-04-21 15:37 ` Detlev Zundel
2011-04-21 15:19 ` Detlev Zundel
2011-04-21 15:46 ` Detlev Zundel
2011-04-23 15:29 ` Andreas Pretzsch
2011-04-27 9:07 ` Detlev Zundel [this message]
2011-04-21 16:10 ` Scott Wood
2011-04-22 0:43 ` Graeme Russ
2011-04-22 6:18 ` Albert ARIBAUD
2011-04-22 10:56 ` Graeme Russ
2011-04-22 8:54 ` Wolfgang Denk
2011-04-22 10:52 ` Graeme Russ
2011-04-22 12:46 ` Wolfgang Denk
2011-04-25 5:37 ` Graeme Russ
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=m2vcy0cbaj.fsf@ohwell.denx.de \
--to=dzu@denx.de \
--cc=u-boot@lists.denx.de \
/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