Re: [PATCH v3 1/3] clang-format: re-adjust line break penalties

[Taylor Blau <me@ttaylorr.com>]

On Mon, Oct 14, 2024 at 11:08:29AM +0200, Toon Claes wrote:
> Karthik Nayak <karthik.188@gmail.com> writes:
>
> [snip]
>
> > This avoids weird formatting like:
> >
> >    static const struct strbuf *
> >           a_really_really_large_function_name(struct strbuf resolved,
> >           const char *path, int flags)
> >
> > or
> >
> >    static const struct strbuf *a_really_really_large_function_name(
> >    	    struct strbuf resolved, const char *path, int flags)
> >
> > to instead have something more readable like:
> >
> >    static const struct strbuf *a_really_really_large_function_name(struct strbuf resolved,
> >           const char *path, int flags)
> >
> > This is done by bumping the values of 'PenaltyReturnTypeOnItsOwnLine'
> > and 'PenaltyBreakOpenParenthesis' to 300. This is so that we can allow a
> > few characters above the 80 column limit to make code more readable.
>
> I'm really liking the idea of penalties, but I feel we're relying too
> much on guestimation of these values. What do you think about adding
> example files to our codebase? Having concrete examples at hand will
> allow us to tweak the values in the future, while preserving behavior
> for existing cases. Or when we decide to change them, we understand
> what and when.

I am not sure I see it the same way.

I might just be ill-informed or not experienced with these clang-format
rules, but having these penalties be defined as such makes it difficult
to reason about what lines will and won't be re-wrapped as a result of
running the formatter.

What is the purpose of these penalties?

Thanks,
Taylor