[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CANiq72ntjDRyMBdVXLMV9h=3_jU47UA06LaGvR2Jw9aMZM3V3w@mail.gmail.com>
Date: Thu, 12 Sep 2019 16:42:03 +0200
From: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
To: Joe Perches <joe@...ches.com>
Cc: Dan Williams <dan.j.williams@...el.com>,
Jens Axboe <axboe@...nel.dk>,
Dan Carpenter <dan.carpenter@...cle.com>,
Dave Jiang <dave.jiang@...el.com>,
ksummit <ksummit-discuss@...ts.linuxfoundation.org>,
linux-nvdimm <linux-nvdimm@...ts.01.org>,
Vishal Verma <vishal.l.verma@...el.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
bpf@...r.kernel.org
Subject: Re: [Ksummit-discuss] [PATCH v2 3/3] libnvdimm, MAINTAINERS:
Maintainer Entry Profile
On Thu, Sep 12, 2019 at 12:18 PM Joe Perches <joe@...ches.com> wrote:
>
> I don't think that's close to true yet for clang-format.
I don't expect clang-format to match perfectly our current code style.
However, if core maintainers agree that it is "close enough now"
(specially with newer LLVMs, like 9), then there is a great benefit on
moving to automatically-styled code. The "con" is having to change a
bit our style wherever clang-format does not support exactly our
current style.
> For instance: clang-format does not do anything with
> missing braces, or coalescing multi-part strings,
> or any number of other nominal coding style defects
> like all the for_each macros, aligning or not aligning
> columnar contents appropriately, etc...
Some of these may or may not be fixable tweaking the options. Note
that there are conflicting styles within the kernel at the moment,
e.g. how to indent arguments to function calls. Therefore, some of the
differences do not apply as soon as we decide on a given style.
Furthermore, with automatic formatting we have also the chance to
review some options that we couldn't easily change before.
> clang-format as yet has no taste.
>
> I believe it'll take a lot of work to improve it to a point
> where its formatting is acceptable and appropriate.
>
> An AI rather than a table based system like clang-format is
> more likely to be a real solution, but training that AI
> isn't a thing that I want to do.
I don't think we need taste (or AI-like solutions), because
consistency has a lot of value too. Not just for our brains, but for
patches as well.
Note that clang-format is a tool used by major projects successfully,
it is not like we are experimenting too much here :-)
Cheers,
Miguel
Powered by blists - more mailing lists