From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail02.groups.io (mail02.groups.io [66.175.222.108]) by spool.mail.gandi.net (Postfix) with ESMTPS id A9F7C78003C for ; Thu, 23 Nov 2023 01:44:23 +0000 (UTC) DKIM-Signature: a=rsa-sha256; bh=LibPm94h+8n9P2NgBbbVs0k8yHUqpJpnFTgFBIuPfPc=; c=relaxed/simple; d=groups.io; h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject:To:Cc:Precedence:List-Subscribe:List-Help:Sender:List-Id:Mailing-List:Delivered-To:Reply-To:List-Unsubscribe-Post:List-Unsubscribe:Content-Type:Content-Transfer-Encoding; s=20140610; t=1700703862; v=1; b=b1u39J/N8PyxFWqB+EOE2O/LFkJKxn2JPRBGJa/B0bTx8FuHYd0TcNM5c1HQX8Yuw20+pgxM yXaSXagjI8eaucS7ClsrWDkwPR9bzsAVXmEyu8VkYUHswc5LYPZn4uZ0AUSx2ss0zhZs84AMy94 dbZ83ZqLlOpQSP9SgQlmVkvs= X-Received: by 127.0.0.2 with SMTP id tp5gYY7687511xqgHRghv4wt; Wed, 22 Nov 2023 17:44:22 -0800 X-Received: from mail-ua1-f47.google.com (mail-ua1-f47.google.com [209.85.222.47]) by mx.groups.io with SMTP id smtpd.web11.82784.1700703861544331375 for ; Wed, 22 Nov 2023 17:44:21 -0800 X-Received: by mail-ua1-f47.google.com with SMTP id a1e0cc1a2514c-7c44f5f3ca2so103521241.0 for ; Wed, 22 Nov 2023 17:44:21 -0800 (PST) X-Gm-Message-State: 3XDfKbtmBBQw8ZIBuzTKxNAgx7686176AA= X-Google-Smtp-Source: AGHT+IGd6pT/PCIuTQQ5olNQe9MT9Ddtei+noSmlA4CoWR9ZVN5JQomBdrA4aDlfsKUFi+8ZxzIb7H9t31hF3BASSU8= X-Received: by 2002:a67:c007:0:b0:45d:8a91:5465 with SMTP id v7-20020a67c007000000b0045d8a915465mr3798374vsi.26.1700703860479; Wed, 22 Nov 2023 17:44:20 -0800 (PST) MIME-Version: 1.0 References: <0107c96b-849a-db48-194b-1a4c1f3b0c78@redhat.com> <23dd696a-52a1-4c26-bfb6-5b5587325c42@linux.microsoft.com> <30e9b11c-ab39-4266-8981-5242542b625d@bsdio.com> <59767c3d-f79a-15fc-b498-3aa829ce3450@redhat.com> In-Reply-To: <59767c3d-f79a-15fc-b498-3aa829ce3450@redhat.com> From: "Pedro Falcato" Date: Thu, 23 Nov 2023 01:44:09 +0000 Message-ID: Subject: Re: [edk2-devel] edk2 uncrustify update (73.0.8)? To: Laszlo Ersek Cc: devel@edk2.groups.io, Rebecca Cran , mikuback@linux.microsoft.com, Michael Kinney , Andrew Fish , Marcin Juszkiewicz , "Leif Lindholm (Quic)" Precedence: Bulk List-Subscribe: List-Help: Sender: devel@edk2.groups.io List-Id: Mailing-List: list devel@edk2.groups.io; contact devel+owner@edk2.groups.io Reply-To: devel@edk2.groups.io,pedro.falcato@gmail.com List-Unsubscribe-Post: List-Unsubscribe=One-Click List-Unsubscribe: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-GND-Status: LEGIT Authentication-Results: spool.mail.gandi.net; dkim=pass header.d=groups.io header.s=20140610 header.b="b1u39J/N"; dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=gmail.com (policy=none); spf=pass (spool.mail.gandi.net: domain of bounce@groups.io designates 66.175.222.108 as permitted sender) smtp.mailfrom=bounce@groups.io On Fri, Nov 17, 2023 at 9:08=E2=80=AFAM Laszlo Ersek wr= ote: > > On 11/16/23 09:29, Pedro Falcato wrote: > > On Tue, Nov 14, 2023 at 3:01=E2=80=AFPM Laszlo Ersek wrote: > >> > >> On 11/13/23 22:33, Pedro Falcato wrote: > >>> On Mon, Nov 13, 2023 at 8:37=E2=80=AFPM Rebecca Cran wrote: > >>>> > >>>> On 11/13/2023 1:08 PM, Michael Kubacki wrote: > >>>>> Yes. I just did it. It is relatively minor and impacts expected cod= e > >>>>> areas. > >>>>> > >>>>> https://github.com/tianocore/edk2/pull/5043/files > >>>> > >>>> > >>>> Could you update .git-blame-ignore-revs please? > >>> > >>> You can't do that until the merge is done, since we use > >>> rebase-and-merge for tianocore (and rebases do not keep stable commit > >>> hashes). > >>> But I would plead that this should not get merged in general :/ > >> > > > > Laszlo! > > > > Sorry for the delay. > > > >> Seeing the cumulative diff in that PR, do you have specific > >> counter-arguments? > > > > Well, my counter-argument is that formatting is becoming a topic of > > its own. I used to be very pro-formatter but if this leads to either > > 1) eyesore or 2) weird churn every now and then, > > I feel like we should reconsider the current approach. I feel like all > > formatting (manual or automated) is fine as long as it's: > > 1) Visually consistent with the codebase's style > > 2) Not horrendous to look at > > That was what we did first, for several years. It wasn't working well. > > An edk2 coding style document had always existed, but it had sufficient > corner cases that formatting had *always* been a topic of its own. In > particular, point (2) "not horrendous to look at" is impossible to define= . > > - edk2 mainly uses a Windows-like coding style, which is immediately > horrendous to anyone coming from a Linux background, at first FWIW, this is a point so annoying that normal formatting tools don't work. It makes you need a fork of an obscure formatter (I know 1 project that uses uncrustify - EDK2...), instead of something more conventional such as clang-format. And, FWIW, I've seen a couple of approximations of the NT kernel style for clang-format. > > - edk2 uses extremely long lines in some modules (200+ characters). I > personally use 80 character lines (for good reason -- not the greatest > eyesight, so I need to use a relatively large font, and I like to place > two columns of source code on my screen side-by-side, for diffing or > comparing otherwise). I've received multiple "buy a larger monitor" or > "use two monitors at the same time", and those don't work for me either. > Some people are super productive with 30" monitors, I'm not. Therefore, > "long lines or not" can never be decided by democracy, only by decree. > uncrustify is decree. > > - somewhat as a consequence of my avoidance of long lines, I tended to > break up long function calls earlier / more frequently than other > developers. In order to conserve *vertical* screen real estate, I used a > "condensed" multi-line argument style for function calls, in OvmfPkg and > ArmVirtPkg. (The official multi-line style is more wasteful.) That > wasn't working for other project participants. Uncrustify now does not > permit my preferred (condensed) style, but at least there are no more > debates about it. > > Your premise is that those two points form a stable foundation, but they > don't. We tried. I may be too naive, but with a *well defined* coding style and a formatter to *help*, I don't see how things would end up poorly. I think a formatter's job should be to *aid*, to not enforce. These things are fallible. For instance, clang-format eyesore out of one of my personal projects: #define ONES ((size_t) -1 / UCHAR_MAX) #define HIGHS (ONES * (UCHAR_MAX / 2 + 1)) #define HASZERO(x) (((x) -ONES) & ~(x) &HIGHS) (may be hard to see in email, but note how clang-format has no idea how any macro works, so (x) - ONES becomes (x) -ONES and & HIGHS becomes &HIGHS...) For instance, I think Linux manages this quite nicely. They provide a .clang-format you can use, and the formatting generally ends up fine. But you're not expected to re-format every couple of changes, not everyone is at the same formatter version (if at all!) and "human thinks looks fine" has higher priority over "*formatter* thinks it looks fine". --=20 Pedro -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#111639): https://edk2.groups.io/g/devel/message/111639 Mute This Topic: https://groups.io/mt/102559740/7686176 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io] -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-