lkml.org 
[lkml]   [2020]   [Nov]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [RFC PATCH] .clang-format: Remove conditional comments
From
Date
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@gmail.com> wrote:
> > On Tue, Nov 3, 2020 at 7:29 PM Joe Perches <joe@perches.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@perches.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@intel.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);


\
 
 \ /
  Last update: 2020-11-04 02:33    [W:0.094 / U:0.844 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site