Re: run pgindent on a regular basis / scripted manner
От | Andrew Dunstan |
---|---|
Тема | Re: run pgindent on a regular basis / scripted manner |
Дата | |
Msg-id | de0a7034-0186-1f91-b408-eb67f2a854dc@dunslane.net обсуждение исходный текст |
Ответ на | Re: run pgindent on a regular basis / scripted manner (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: run pgindent on a regular basis / scripted manner
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: