Taylor Blau <me@xxxxxxxxxxxx> writes: > 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? > We have a column limit set in our clang-format 'ColumnLimit: 80', this dictates when line breaks should occur in our code. The penalties are options through which we can influence this decision [1]. > Thanks, > Taylor [1]: https://stackoverflow.com/a/27608250
Attachment:
signature.asc
Description: PGP signature
