Re: run pgindent on a regular basis / scripted manner
От | Peter Geoghegan |
---|---|
Тема | Re: run pgindent on a regular basis / scripted manner |
Дата | |
Msg-id | CAH2-WzmGAEhX6TJptz_Acug5GKYUSPKFDX8vdzDPDZuOTppDJg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: run pgindent on a regular basis / scripted manner (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
On Sun, Jan 22, 2023 at 3:28 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: > So the more I think about it the less excited I am about depending on > clang-format, because version skew in peoples' clang installations seems > inevitable, and there's good reason to fear that that would show up > as varying indentation results. I have to admit that the way that I was thinking about this was colored by the way that I use clang-format today. I only now realize how different my requirements are to the requirements that we'd have for any tool that gets run against the tree in bulk. In particular, I didn't realize how annoying the non-additive nature of certain variable alignment rules might be until you pointed it out today (seems obvious now!). In my experience clang-format really shines when you need to quickly indent code that is indented in some way that looks completely wrong -- it does quite a lot better than pgindent when that's your starting point. It has a reasonable way of balancing competing goals like maximum number of columns (a soft maximum) and how function parameters are displayed, which pgindent can't do. It also avoids allowing a function parameter from a function declaration with its type name on its own line, before the variable name -- also beyond the capabilities of pgindent IIRC. Features like that make it very useful as a first pass thing, where all the bells and whistles have little real downside. Running clang-format and then running pgindent tends to produce better results than just running pgindent, at least when working on a new patch. -- Peter Geoghegan
В списке pgsql-hackers по дате отправления: