From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.7 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 56C12C2D0A3 for ; Wed, 4 Nov 2020 01:32:02 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 1212B223C7 for ; Wed, 4 Nov 2020 01:32:02 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729934AbgKDBcB (ORCPT ); Tue, 3 Nov 2020 20:32:01 -0500 Received: from smtprelay0085.hostedemail.com ([216.40.44.85]:36786 "EHLO smtprelay.hostedemail.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1725769AbgKDBcA (ORCPT ); Tue, 3 Nov 2020 20:32:00 -0500 Received: from filter.hostedemail.com (clb03-v110.bra.tucows.net [216.40.38.60]) by smtprelay06.hostedemail.com (Postfix) with ESMTP id EF1E418225E0A; Wed, 4 Nov 2020 01:31:58 +0000 (UTC) X-Session-Marker: 6A6F6540706572636865732E636F6D X-HE-Tag: bells46_5806729272bd X-Filterd-Recvd-Size: 4539 Received: from XPS-9350.home (unknown [47.151.133.149]) (Authenticated sender: joe@perches.com) by omf18.hostedemail.com (Postfix) with ESMTPA; Wed, 4 Nov 2020 01:31:57 +0000 (UTC) Message-ID: Subject: Re: [RFC PATCH] .clang-format: Remove conditional comments From: Joe Perches To: Nick Desaulniers , Miguel Ojeda Cc: clang-built-linux , LKML Date: Tue, 03 Nov 2020 17:31:56 -0800 In-Reply-To: References: <363325b4a85f094ba9cf06301dd022912ec79d03.camel@perches.com> Content-Type: text/plain; charset="ISO-8859-1" User-Agent: Evolution 3.38.1-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 2020-11-03 at 17:08 -0800, Nick Desaulniers wrote: > On Tue, Nov 3, 2020 at 1:33 PM Miguel Ojeda > wrote: > > On Tue, Nov 3, 2020 at 7:29 PM Joe Perches 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 > > > --- > > > > > > 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 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);