From: Hugh Dickins <hughd@google.com>
To: Joe Perches <joe@perches.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>,
Andrew Morton <akpm@linux-foundation.org>,
Alexander Kuleshov <kuleshovmail@gmail.com>,
Miklos Szeredi <miklos@szeredi.hu>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] fs: overlayfs: Fix coding style issues, missing a blank line after declarations
Date: Sun, 28 Dec 2014 19:38:07 -0800 (PST) [thread overview]
Message-ID: <alpine.LSU.2.11.1412281912360.1328@eggly.anvils> (raw)
In-Reply-To: <1419822060.18886.1.camel@perches.com>
On Sun, 28 Dec 2014, Joe Perches wrote:
> On Mon, 2014-12-29 at 02:49 +0000, Al Viro wrote:
> > On Mon, Dec 29, 2014 at 02:39:39AM +0000, Al Viro wrote:
> > > On Sun, Dec 28, 2014 at 11:56:53AM +0600, Alexander Kuleshov wrote:
> > > > Signed-off-by: Alexander Kuleshov <kuleshovmail@gmail.com>
> > > > ---
> > >
> > > For the record: anything of that sort against fs/*.c will be flushed down
> > > the toilet where such valuable contributions belong. Don't even bother.
> >
> > Joe, could you please explain what has driven you to include that into
> > scripts/checkpatch.pl and open the countless sphincters? Aren't we
> > getting enough pointless patches as it is?
>
> I don't care for that style actually.
> It was Andrew Morton that wanted it used globally.
>
> I wanted it to be a --strict test and only for
> net/ and drivers/net/ where David Miller prefers
> that style.
>
> https://lkml.org/lkml/2014/3/6/550
Although I am guilty of inflicting it on others, just so their patches
keep checkpatch.pl quiet, I have been finding this rule very counter-
productive, and often at odds with long-established good practice.
It makes sense at the head of a substantial function declaring a
collection of variables; but Alexander's patch gives many fine examples
of where it is stupid, and thank you to him for showing it up so well.
In a wrapper function which finds it convenient to declare and assign
a variable before doing a line or two and returning, a common pattern,
a blank line is just distracting hot air to pacify checkpatch.pl.
In a block which needs one extra local variable to do its work, I find
the rule pushes me to move that declaration to the head of the function
instead of keeping it local to the block, just to avoid the unnecessary
blank line.
Please rescind or refine the rule - thanks.
Hugh
prev parent reply other threads:[~2014-12-29 3:38 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-28 5:56 Alexander Kuleshov
2014-12-29 2:39 ` Al Viro
2014-12-29 2:49 ` Al Viro
2014-12-29 3:01 ` Joe Perches
2014-12-29 3:38 ` Hugh Dickins [this message]
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=alpine.LSU.2.11.1412281912360.1328@eggly.anvils \
--to=hughd@google.com \
--cc=akpm@linux-foundation.org \
--cc=joe@perches.com \
--cc=kuleshovmail@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=miklos@szeredi.hu \
--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
all inboxes | Powered by JetHome®