On Sun, Jan 22, 2023 at 3:28 PM Tom Lane <t...@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
