Thread: Adding a clang-format file
Like other Postgres hackers [1], I have a custom .clang-format file that I use for my work on Postgres. It's a useful tool, despite some notable problems. First, I should mention the problems. The config that I use makes an awkward trade-off that results in function declarations getting mangled. This trade-off seems unavoidable, perhaps owing to a design problem with the tool. I also generally prefer the way that pgindent indents blocks of variables at the start of each scope; clang-format aligns them in a column-perfect way, which is less aesthetically pleasing and more distracting than what pgindent will do. clang-format also has some notable advantages over pgindent when used as a tool, day to day. I find that clang-format can reliably fix some things that pgindent just won't fix. This includes misformated function parameters with a line break that puts the name on a separate line to the type. As a general rule, it tends to do better with code that is *very* poorly formatted. It also has the advantage of being easy to run from my text editor. It can reformat even a range of lines in a way that is passably close to Postgres style, without any of the hassles of setting up pgindent. Since many of us are using clang-format anyway, it occurs to me that we should perhaps commit a clang-format dot file, so that new contributors have a reasonable way of formatting code that "just works". Using pgindent is easy enough when you get used to it, but it's not easy to set up for the first time. I think that some editors can use a project's clang-format file automatically, even. If a new contributor can use the existing clang-format file it's likely to be significantly better than using nothing. I really don't see any real problem with making something available, without changing any official project guidelines. It's commonplace to provide a clang-format file these days. [1] https://www.postgresql.org/message-id/flat/55665327.2060508%40gmx.net#080983bfcee12d46a33854e1064fdcca -- Peter Geoghegan
Hi Peter, > I really don't see any real problem with making something available, > without changing any official project guidelines. It's commonplace to > provide a clang-format file these days. Personally I don't have anything against the idea. TimescaleDB uses clang-format to mimic pgindent and it works quite well. One problem worth mentioning though is that the clang-format file is dependent on the particular version of clang-format. TSDB requires version 7 or 8 and the reason why the project can't easily switch to a newer version is that the format has changed. So perhaps a directory would be more appropriate than a single file. -- Best regards, Aleksander Alekseev
On Tue, Sep 27, 2022 at 5:35 AM Aleksander Alekseev <aleksander@timescale.com> wrote: > Personally I don't have anything against the idea. TimescaleDB uses > clang-format to mimic pgindent and it works quite well. One problem > worth mentioning though is that the clang-format file is dependent on > the particular version of clang-format. I was hoping that something generic could work here. Something that we could provide that didn't claim to be authoritative, that has a reasonable degree of compatibility that allows most people to use the file without much fuss. Kind of like our .editorconfig file. That might not be a realistic goal, though, since the clang-format settings are all quite complicated. -- Peter Geoghegan
Hi, Just wondering would you mind sharing your .clang-format file? I find the attachment you pointed to is only a demo with a “…” line and it doesn’t format PG code very well. btw I’m also greatly in favor of this idea. clang-format is tightly integrated into CLion and it’s very convenient. right now I’m using a CLion preset by Greenplum [1] but it doesn’t handle struct fields and variables column alignment very well. [1] https://groups.google.com/a/greenplum.org/g/gpdb-dev/c/rDYSYotssbE/m/7HgsWuj7AwAJ > On Sep 28, 2022, at 08:43, Peter Geoghegan <pg@bowt.ie> wrote: > > On Tue, Sep 27, 2022 at 5:35 AM Aleksander Alekseev > <aleksander@timescale.com> wrote: >> Personally I don't have anything against the idea. TimescaleDB uses >> clang-format to mimic pgindent and it works quite well. One problem >> worth mentioning though is that the clang-format file is dependent on >> the particular version of clang-format. > > I was hoping that something generic could work here. Something that we > could provide that didn't claim to be authoritative, that has a > reasonable degree of compatibility that allows most people to use the > file without much fuss. Kind of like our .editorconfig file. That > might not be a realistic goal, though, since the clang-format settings > are all quite complicated. > > -- > Peter Geoghegan > > >