Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pNzBW-0000Fw-Tf for pgsql-hackers@arkaria.postgresql.org; Fri, 03 Feb 2023 16:45:10 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1pNzBV-0001rL-9O for pgsql-hackers@arkaria.postgresql.org; Fri, 03 Feb 2023 16:45:09 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pNzBU-0001pv-Uz for pgsql-hackers@lists.postgresql.org; Fri, 03 Feb 2023 16:45:08 +0000 Received: from relay3-d.mail.gandi.net ([2001:4b98:dc4:8::223]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pNzBN-0004sW-5f for pgsql-hackers@postgresql.org; Fri, 03 Feb 2023 16:45:07 +0000 Received: (Authenticated sender: adsend@dunslane.net) by mail.gandi.net (Postfix) with ESMTPSA id 0E31460003; Fri, 3 Feb 2023 16:44:47 +0000 (UTC) Content-Type: multipart/alternative; boundary="------------7SmPugAN0GH5Ap1YdfFXK1pn" Message-ID: Date: Fri, 3 Feb 2023 11:44:46 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.5.0 Subject: Re: run pgindent on a regular basis / scripted manner To: Tom Lane , Andres Freund Cc: Jelte Fennema , Peter Geoghegan , Bruce Momjian , Magnus Hagander , Alvaro Herrera , Stephen Frost , Noah Misch , Jesse Zhang , PostgreSQL-development References: <1097305.1674334785@sss.pgh.pa.us> <20230121224312.qmwpagrebidr6hi7@awork3.anarazel.de> <20230122094957.x542ojaqgi4lalq4@awork3.anarazel.de> <20230122223806.3sgew6qswhsczae7@awork3.anarazel.de> <1489276.1674427657@sss.pgh.pa.us> Content-Language: en-US From: Andrew Dunstan In-Reply-To: <1489276.1674427657@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk This is a multi-part message in MIME format. --------------7SmPugAN0GH5Ap1YdfFXK1pn Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 2023-01-22 Su 17:47, Tom Lane wrote: > Andres Freund writes: >> I strongly dislike it, I rarely get it right by hand - but it does have some >> benefit over aligning variable names based on the length of the type names as >> uncrustify/clang-format: In their approach an added local variable can cause >> all the other variables to be re-indented (and their initial value possibly >> wrapped). The fixed alignment doesn't have that issue. > Yeah. That's one of my biggest gripes about pgperltidy: if you insert > another assignment in a series of assignments, it is very likely to > reformat all the adjacent assignments because it thinks it's cool to > make all the equal signs line up. That's just awful. You can either > run pgperltidy on new code before committing, and accept that the feature > patch will touch a lot of lines it's not making real changes to (thereby > dirtying the "git blame" history) or not do so and thereby commit code > that's not passing tidiness checks. Let's *not* adopt any style that > causes similar things to start happening in our C code. Modern versions of perltidy give you much more control over this, so maybe we need to investigate the possibility of updating. See the latest docco at <*https://metacpan.org/dist/Perl-Tidy/view/bin/perltidy#Completely-turning-off-vertical-alignment-with-novalign> * Probably we'd want to use something like |--valign-exclusion-list=||'= => ,'| || || |cheers| || |andrew| -- Andrew Dunstan EDB:https://www.enterprisedb.com --------------7SmPugAN0GH5Ap1YdfFXK1pn Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit


On 2023-01-22 Su 17:47, Tom Lane wrote:
Andres Freund <andres@anarazel.de> writes:

I strongly dislike it, I rarely get it right by hand - but it does have some
benefit over aligning variable names based on the length of the type names as
uncrustify/clang-format: In their approach an added local variable can cause
all the other variables to be re-indented (and their initial value possibly
wrapped). The fixed alignment doesn't have that issue.

Yeah.  That's one of my biggest gripes about pgperltidy: if you insert
another assignment in a series of assignments, it is very likely to
reformat all the adjacent assignments because it thinks it's cool to
make all the equal signs line up.  That's just awful.  You can either
run pgperltidy on new code before committing, and accept that the feature
patch will touch a lot of lines it's not making real changes to (thereby
dirtying the "git blame" history) or not do so and thereby commit code
that's not passing tidiness checks.  Let's *not* adopt any style that
causes similar things to start happening in our C code.


Modern versions of perltidy give you much more control over this, so maybe we need to investigate the possibility of updating. See the latest docco at <https://metacpan.org/dist/Perl-Tidy/view/bin/perltidy#Completely-turning-off-vertical-alignment-with-novalign>

Probably we'd want to use something like 

--valign-exclusion-list='= => ,'




cheers


andrew


--
Andrew Dunstan
EDB: https://www.enterprisedb.com
--------------7SmPugAN0GH5Ap1YdfFXK1pn--