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