RE: automated coding style tool

On Wednesday, January 15, 2025 11:20 AM Luis Machado wrote:
> 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.

FWIW, I'd also be in favor of having a clang-format configuration available
in the GDB repo.  Such tools will always have false-positives and may require
some human involvement occasionally.  I think the potential benefits are appealing.

Regards,
-Baris


Intel Deutschland GmbH
Registered Address: Am Campeon 10, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de
Managing Directors: Sean Fennelly, Jeffrey Schneiderman, Tiffany Doon Silva
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928