From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
---|---|
To: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Adding a clang-format file |
Date: | 2022-09-27 02:56:23 |
Message-ID: | CAH2-WzkoHO=Rr+53C0u4QPxG8kVYrGWy2+JczL+APyhjdryq3w@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | James Coleman | 2022-09-27 02:58:16 | Re: cirrus-ci cross-build interactions? |
Previous Message | James Coleman | 2022-09-27 02:56:11 | Re: Parallelize correlated subqueries that execute within each worker |