Messages in this thread | | | Subject | Re: [RFC PATCH] .clang-format: Remove conditional comments | From | Joe Perches <> | Date | Tue, 03 Nov 2020 17:31:56 -0800 |
| |
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);
| |