Re: automated coding style tool

[Simon Marchi via Gdb <gdb@sourceware.org>]

On 1/17/25 12:36 PM, Phi via Gdb wrote:
> 
> 
> On 17/01/2025 16:55, Simon Marchi via Gdb wrote:
> 
>>
>> Of course, like Joel said, ill-formatted code will certainly get
>> committed at some point, but the nightly job will tell us.  It's a quick
> 
> Just curious about this interesting thread. I'd like to understand the ill-formatted concept while using a code formatter. I was wondering a !ill-formatted, i.e a well-formatted should always produce a no diff output on its input, I mean 
> 
> $ format-tool foo.c
> 
> must produce foo.c with no diff's

I once had a situation where clang-format would ping pong between two
formattings for a given line of code when running multiple times on the
same file.  This was an unfortunate bug, but easily circumvented by
adding a /* clang-format off */ annotation.  Given the amount of code
that this tool has formatted without any problem for me, I can forgive
this one bug :).

> a hook of some kind can be implemented may be at commit or push time (or git-send-mail) saying the format-tool must be run first and QA re-run. 

We were discussing the merits of using a tool to format the code if
there is not pre-push check, if the responsibility to run the tool
solely falls on each contributor doing it on their side.  Some
ill-formatted code will get pushed at some point.  My point is that it's
not the end of the world, and it's still better than using no tool at
all.  But of course, something that blocks the push if ill-formatted
code is present is even better.

Simon