git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: .clang-format: how useful, how often used, and how well maintained?

From
Johannes Schindelin <johannes.schindelin@gmx.de>
Date
Jul 1, 2025, 16:59 UTC
Message-ID
<49a3ae89-850b-64b0-e3cc-70a068171352@gmx.de>
In-Reply-To
<875xgcq9zf.fsf@iotcl.com>
Hi Toon,
On Tue, 1 Jul 2025, Toon Claes wrote:
Show 36 quoted lines
> Junio C Hamano <gitster@pobox.com> writes:
> 
> > "brian m. carlson" <sandals@crustytoothpaste.net> writes:
> >
> >> I still think that if we're going to have this functionality and
> >> expect it to be used, we need to make it the default, build
> >> appropriate tooling, and check it in CI.  If it's not
> >> fire-and-forget, people won't use it.
> >
> > There probably needs some balancing act, as I already pointed out,
> > what clang-format gives often do not make sense, and the point is that
> > they are not about styles (where we can safely say "no style is liked
> > by everybody") but about how readable the result is (which sometimes
> > is subjective but more often it is not).  Until the tool and its
> > configuration is polished enough, blindly applying the result with
> > fire-and-forget mentality will degrade the quality of our codebase.
> 
> Allow me to share an unpopular opinion. I think you either fully commit
> to a formatter, or you don't care about formatting at all. I realize
> that's probably overly strict for most people, but I've been working
> mostly in Golang for several years, and having a tool that formats code
> and it's output is unarguably the standard is a bliss.
> 
> I think the only way we can stop bikeshedding about formatting, is by
> adopting clang-format and make it's output the golden standard. We might
> not like it's output (similar to many people do not like `gofmt`s
> output), but it's a standard. If we have to wait for clang-format to
> support all the configuration options we prefer, we will be having this
> conversation over and over again over time. I don't think that's worth
> it.
> 
> Code formatting should be the job of an automated tool, not a person.
> It's annoying to have this back-and-forth in reviews because it's not
> following the standard _the Git project_ has set, while it would be a
> lot less friction to follow a standard that's set by _the formatting
> tool_.

For the record, I share this opinion, and I don't even think that it is unpopular. There is a reason why there's ESLint, gofmt, rustfmt, RuboCop, etc. Even cURL comes with a helpful `make checksrc` with little room for distracting nitpicks about code style, making more room for a focus on correct code.

Ciao, Johannes

Previous: Toon ClaesNext: Junio C Hamano
Message 13 of 18 in “.clang-format: how useful, how often used, and how well maintained?”
  1. Junio C HamanoJun 19, 2025
  2. Christian CouderJun 19, 2025
  3. Junio C HamanoJun 20, 2025
  4. Christian CouderJun 20, 2025
  5. Junio C HamanoJun 20, 2025
  6. Jeff KingJun 21, 2025
  7. Junio C HamanoJun 22, 2025
  8. brian m. carlsonJun 19, 2025
  9. Collin FunkJun 19, 2025
  10. brian m. carlsonJun 19, 2025
  11. Junio C HamanoJun 20, 2025
  12. Toon ClaesJul 1, 2025
  13. Johannes SchindelinJul 1, 2025
  14. Junio C HamanoJul 1, 2025
  15. Junio C HamanoJul 1, 2025
  16. Karthik NayakJun 23, 2025
  17. Junio C HamanoJun 23, 2025
  18. Karthik NayakJun 24, 2025

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.