Toon Claes <toon@xxxxxxxxx> writes: > 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 That is true indeed. There is a bit of guestimation done here, I had to try various values to find the ones which worked well. I wish there was a more formal way to do this... > 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. > I'm not too keen on adding examples, for the mere facts that: 1. They will be outdated each time we change rules. 2. The commit message already has the information around each rule. Karthik
Attachment:
signature.asc
Description: PGP signature
