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

From: Junio C Hamano <[email-masked]>
Date: Fri, 20 Jun 2025 09:36:58 -0700

Christian Couder <[email-masked]> writes:

> It's up to each one to decide if they prefer post-commit or pre-commit
> hooks or other ways to trigger the style check. So yeah, we could both
> suggest using hooks and add a format-patch option to make it easier
> for those who don't want a hook.

The thing is, I have no idea what the "option" to format-patch you
talk about should look like.  This topic is about improving Git
codebase by helping Git developers, and I do not want to add a
project-specific option to the tool that is meant for the general
public.

>> Or just write that command invocation into "MyFirstContribution" etc.?
>
> Yeah, we could do that too.

I think that is a good first step.  Give an example that shows that
the tool can give suboptimal suggestions as well as good ones, to
stress the point that the output from the tool should not be taken
blindly, but should still be looked at.

>> What I called "once the code is written" is something I would refuse
>> to accept as a "style fix" patch, but they are still improvements
>> and it would be great if contributors followed these style checker's
>> suggestion _before_ sending the patch to the list.
>
> If we encourage a style checker to make suggestions that are often in
> bikeshedding territory, then I think we take the risks of:

I do not think I am advocating to encourage a style checker to make
bikeshedding suggestions at all.  We are not discussing any change
to .clang-format file in this discussion (a side thread we discussed
about concluding a year-old experiment, which would result in a small
change to the file, though).

>   - annoying some users who disagree with some suggestions,

That I do not think we care too much.  This is not about "users".

>   - having bikeshedding discussions on the list (like this one) about
> things that are just not worth it,

But now we have a good thing to point at.  "You want to bikeshed?
Let's see what clang-format with our recommended setting says."  And
the discussion should end there.

>   - the style checker being actually wrong (because of the context for example).

If you are worried about "bikeshedding territory", there is no
additional risks for the tool to be actually wrong.  Whether you
blindly take its stylistic changes or not, you'd need to be careful
about tool changing the meanings of the code it is touching.

> In my opinion the possible small gains are not worth taking those
> risks.

So, from my point of view, I am not sure if there is _any_ risks,
but again I do not know who you think is advocating for more
bikeshedding via the style checker.

> In other words from a style checker I'd rather have fewer
> suggestions that are more likely to be right, than more suggestions
> that are more likely to be dubious.

No question about that, but I see no logical linkage between what
you said above and this goal, sorry.

> I agree that in the example above the suggested change might be good.

> But if there is ...

Don't move the goalpost.  It is not the case we are discussing.

> So my opinion is that a style checker that doesn't take into account
> the length of the lines around where it makes suggestions is likely to
> make a number of wrong line wrapping suggestions.

Your example is not even about "around", but the exact line that is
being changed, isn't it?  Even if the line being changed were the
only overly long line, and all lines around it were below the length
that is comfortably read with minimal horizontal eye movement, we
still want to wrap it down, don't we?