On Mon, Oct 14, 2024 at 11:08:29AM +0200, Toon Claes wrote: > Karthik Nayak <karthik.188@xxxxxxxxx> 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