Thread (39 messages) 39 messages, 5 authors, 2024-10-25

Re: [PATCH v3 1/3] clang-format: re-adjust line break penalties

From: Toon Claes <hidden>
Date: 2024-10-14 09:08:47

Karthik Nayak [off-list ref] 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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help