Re: automated coding style tool

On 1/14/25 23:04, Tom Tromey wrote:
> Simon> If we don't like what the tool outputs, we can argue over than
> Simon> and change the tool.
> 
> Yeah - but that's where we're already at.  Like, I ran clang-format on
> gdb and read the diffs and found a bunch of things I didn't like.  IIRC
> the main offenders were bin-packing.  I imagine Pedro did this too,
> since he's made similar comments in the past.
> 
> I at least CCd myself on upstream bugs against the tool.  I commented
> on some, maybe filed some too (don't remember).
> 
> I'm not super interested in hacking on clang-format, but the tool is
> there and all the information for someone who is.
> 
> Simon> Also, if are missing some features to get the output we want, nobody is
> Simon> going to magically implement them for us.  And if we don't use the tool,
> Simon> there's no motivation for us either to go implement the changes.  I
> Simon> think that the only way to get the ball rolling is to start using the
> Simon> tool, even if the output is not ideal, and then if there's something
> Simon> really annoying, one of us *might* have the motivation to go improve the
> Simon> tool.
> 
> I'm in favor of using a tool but my view is that it has to meet some
> minimal standard of usefulness.  I just think clang-format does not do
> this.

That's fair. But are we factoring in the amount of time spent over the years
telling contributors "you forgot a space here", "two spaces after period"?

I tend to think that is not a good use of one's time. I reviewed some output
from applying clang-format --style=gnu on gdb's sources, and it looks generally
fine to me.

Some stuff is a bit different and some other stuff is very different. But
personally I'm willing to see this automation go through and I'm fine
adapting to a potentially new format, whatever that is.

I might've mentioned this already, but for folks that deal with multiple projects,
the norm is to have to deal with varying styles. So it becomes even more of a burden
to try to remember the GNU style that mostly applies to C and not C++, even though
the project is C++ now.

In summary what I want to say is that I'd go for it. If later we want to tweak
things, we can. This sounds like it agrees with Simon as well.