Toon Claes [off-list ref] writes:

Karthik Nayak [off-list ref] writes:

[snip]

quoted

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