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. Now, I'm not sure where to put such files. I think I would suggest something like t/style-lint or t/clang-format. Anyway, for our tooling it doesn't seem to matter, because both `make style` and `ci/run-style-check.sh` pick up all .c and .h files anywhere in the source tree. Adding a README to that directory will help people understand why the files are there. -- Toon
