Re: [RFC PATCH] .clang-format: Remove conditional comments

[Joe Perches]

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@xxxxxxxxx> wrote: 
> > On Tue, Nov 3, 2020 at 7:29 PM Joe Perches <joe@xxxxxxxxxxx> 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@xxxxxxxxxxx>
> > > ---
> > > 
> > > 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@xxxxxxxxxxx/

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@xxxxxxxxx> 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);