Re: [PATCH v3 1/3] clang-format: re-adjust line break penalties
- From
Taylor Blau <me@ttaylorr.com>
- Date
- Oct 14, 2024, 21:14 UTC
- Message-ID
- <Zw2Jq0cGPrRn6GAO@nand.local>
- In-Reply-To
- <871q0jrr02.fsf@iotcl.com>
On Mon, Oct 14, 2024 at 11:08:29AM +0200, Toon Claes wrote:
Show 30 quoted lines
> 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