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

[Toon Claes <toon@iotcl.com>]

Junio C Hamano <gitster@pobox.com> writes:

> "brian m. carlson" <sandals@crustytoothpaste.net> writes:
>
>> Yeah, then in that case, we probably want to ship some sort of container
>> and script that can do that.  Our default Rust target is Debian stable,
>> so that seems like a decent target if we need to pick a distro.  It's
>> also a very common distro used in containers, so it's widely available
>> to contributors using container-based development environments.

That sounds like the ideal solution.

>> 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_.

-- 
Cheers,
Toon