[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ba3126e1424c578f5040c7a6f04cdd6a334b2db4.camel@perches.com>
Date: Tue, 03 Nov 2020 17:31:56 -0800
From: Joe Perches <joe@...ches.com>
To: Nick Desaulniers <ndesaulniers@...gle.com>,
Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
Cc: clang-built-linux <clang-built-linux@...glegroups.com>,
LKML <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH] .clang-format: Remove conditional comments
On Tue, 2020-11-03 at 17:08 -0800, Nick Desaulniers wrote:
> On Tue, Nov 3, 2020 at 1:33 PM Miguel Ojeda
> <miguel.ojeda.sandonis@...il.com> wrote:
> > On Tue, Nov 3, 2020 at 7:29 PM Joe Perches <joe@...ches.com> wrote:
> > >
> > > Now that the clang minimum supported version is > 10.0, enable the
> > > commented out conditional reformatting key:value lines in the file.
> > >
> > > Signed-off-by: Joe Perches <joe@...ches.com>
> > > ---
> > >
> > > Hey Miguel.
> > >
> > > I don't use this, but on its face it seems a reasonable change
> > > if the commented out key:value lines are correct.
>
> Joe,
> what would it take to get you to use clang-format, or at least try it?
> Beers? Bribes? Dirty deeds, done dirt cheap?
Hey Nick.
Paint my house? ;)
I've tried it. It's OK. It's not significantly better than
Lindent in some ways, in other ways it's pretty good.
It can make a real hash though of well formatted, human readable
code. I think that's it's biggest drawback.
I posted an example of it a year or so back.
https://lore.kernel.org/lkml/e9cb9bc8bd7fe38a5bb6ff7b7222b512acc7b018.camel@perches.com/
In that thread I wrote:
On Thu, 2019-09-12 at 03:18 -0700, Joe Perches wrote:
> On Thu, 2019-09-12 at 10:24 +0200, Miguel Ojeda wrote:
> > On Thu, Sep 12, 2019 at 9:43 AM Dan Williams <dan.j.williams@...el.com> wrote:
> > > Now I come to find that CodingStyle has settled on clang-format (in
> > > the last 15 months) as the new standard which is a much better answer
> > > to me than a manually specified style open to interpretation. I'll
> > > take a look at getting libnvdimm converted over.
> >
> > Note that clang-format cannot do everything as we want within the
> > kernel just yet, but it is a close enough approximation -- it is near
> > the point where we could simply agree to use it and stop worrying
> > about styling issues. However, that would mean everyone needs to have
> > a recent clang-format available, which I think is the biggest obstacle
> > at the moment.
>
> I don't think that's close to true yet for clang-format.
>
> 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...
>
> 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.
and an example very poor conversion from that same thread:
unsigned int key, newkey;
int i;
- rc = sscanf(buf, "%"__stringify(SEC_CMD_SIZE)"s"
- " %"__stringify(KEY_ID_SIZE)"s"
- " %"__stringify(KEY_ID_SIZE)"s",
- cmd, keystr, nkeystr);
+ rc = sscanf(
+ buf,
+ "%" __stringify(
+ SEC_CMD_SIZE) "s"
+ " %" __stringify(
+ KEY_ID_SIZE) "s"
+ " %" __stringify(
+ KEY_ID_SIZE) "s",
+ cmd, keystr, nkeystr);
Powered by blists - more mailing lists