[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190913050031.GB128462@kroah.com>
Date: Fri, 13 Sep 2019 06:00:31 +0100
From: Greg KH <gregkh@...uxfoundation.org>
To: "Aneesh Kumar K.V" <aneesh.kumar@...ux.ibm.com>
Cc: Dan Carpenter <dan.carpenter@...cle.com>,
Dan Williams <dan.j.williams@...el.com>,
Dave Jiang <dave.jiang@...el.com>, linux-nvdimm@...ts.01.org,
Vishal Verma <vishal.l.verma@...el.com>,
linux-kernel@...r.kernel.org, bpf@...r.kernel.org
Subject: Re: [Ksummit-discuss] [PATCH v2 3/3] libnvdimm, MAINTAINERS:
Maintainer Entry Profile
On Fri, Sep 13, 2019 at 07:41:55AM +0530, Aneesh Kumar K.V wrote:
> On 9/12/19 12:13 AM, Dan Carpenter wrote:
> > On Wed, Sep 11, 2019 at 08:48:59AM -0700, Dan Williams wrote:
> > > +Coding Style Addendum
> > > +---------------------
> > > +libnvdimm expects multi-line statements to be double indented. I.e.
> > > +
> > > + if (x...
> > > + && ...y) {
> >
> > That looks horrible and it causes a checkpatch warning. :( Why not
> > do it the same way that everyone else does it.
> >
> > if (blah_blah_x && <-- && has to be on the first line for checkpatch
> > blah_blah_y) { <-- [tab][space][space][space][space]blah
> >
> > Now all the conditions are aligned visually which makes it readable.
> > They aren't aligned with the indent block so it's easy to tell the
> > inside from the if condition.
>
>
> I came across this while sending patches to libnvdimm subsystem. W.r.t
> coding Style can we have consistent styles across the kernel? Otherwise, one
> would have to change the editor settings as they work across different
> subsystems in the kernel. In this specific case both clang-format and emacs
> customization tip in the kernel documentation directory suggest the later
> style.
We _should_ have a consistent coding style across the whole kernel,
that's the whole reason for having a coding style in the first place!
The problem is, we all have agreed on the "basics" a long time ago, but
are now down in the tiny nits as to what some minor things should, or
should not, look like.
It might be time to just bite the bullet and do something like
"clang-format" to stop arguing about stuff like this for new
submissions, if for no other reason to keep us from wasting mental
energy on trivial things like this.
thanks,
greg k-h
Powered by blists - more mailing lists