Re: clang-format

Alejandro Colomar via Mutt-dev <[email protected]> Sun, 15 Mar 2026 13:36:04 +0100
Newsgroups	gmane.mail.mutt.devel
Message-ID	<abamLWomjMq66FkQ@devuan>
Hi Kevin,

On 2026-03-15T10:40:02+0800, Kevin J. McCarthy wrote:
> On Sat, Mar 14, 2026 at 03:29:39PM +0100, Alejandro Colomar via Mutt-dev wrote:
> > On 2026-03-14T18:47:18+0800, Kevin J. McCarthy wrote:
> > > > AlignAfterOpenBracket: Align
> > > 
> > > This is generally the case in the Mutt code.  I think overall it looks nice,
> > > but there is the trade-off with long function names and/or deep indention
> > > where parameters start to not all fit within 80 columns.
> > 
> > I tend to prefer manual adjustment of this.  Most of the time, it's
> > reasonable to use the automatic alignment, but every now and then I
> > decide to differ for some reason.
> 
> Yes, this seems to be the problem with format tools.  AFAICT, there are just
> two options, true and false.  I don't think there is a way to say "let them
> be", but please correct me if I'm wrong.

I've never used clang-format(1), so I don't know.

I think I'd use it unce to make the source more consistent, and then
stop using it, as others have said.  After that, style should get more
consistent, and new code would likely follow the existing style.

Then maybe run it once a year or so, just to check that everything is
more or less good.

I have so far not engaged using these tools precisely because they are
too strict, and that ends up making source code worse.  I still want to
experiment with them, in case I can enforce some rules that are more
simple and which have no exceptions, but I'm not yet convinced.

> Rene voiced a dislike of formatters, especially when they are run
> automatically on a pipeline.  Perhaps we could run this formatter once,
> clean up the egregious function alignment issues, and then just leave the
> format config as "reference"?

+1

> > > > SpaceBeforeParens: Always
> 
> [...]
> 
> > I dislike this.  It becomes especially bad when nesting calls.  Here's
> > for example some code I had to write for GCC, and how I would have
> > written it without the mandatory spaces:
> > 
> > 	_Generic (typeof (_Maxof (const int)), int: 0);
> > 	_Static_assert (_Maxof (unsigned _BitInt (5)) == 31);
> > vs
> > 	_Generic(typeof(_Maxof(const int)), int: 0);
> > 	_Static_assert(_Maxof(unsigned _BitInt(5)) == 31);
> > 
> > The argument list is fundamentally attached to the function, and the
> > lack of space makes that more evident to the eye.  That separate (5)
> > seems lost, where it is in reality the argument of _BitInt().
> 
> I won't argue with this.  I'm used to the space before the parens now, after
> a few years of working in the code.  But when nested calls take place, I
> agree that it becomes unreadable.  And unfortunately the formatter does it
> for gettext parameters too, so we have calls like:
> 
>   getFoo (_ ("hey there"), 1);

lol

> which I think looks terrible.

Indeed.

> I'm still very reluctant to change the default format after so long. But if
> I heard from some of the Mutt old timers in support, perhaps we could take
> the plunge...


Have a lovely day!
Alex

-- 
<https://www.alejandro-colomar.es>
signature.asc (application/pgp-signature, 833 B)