From: Toon Claes <toon@iotcl.com>
To: Karthik Nayak <karthik.188@gmail.com>, karthik.188@gmail.com
Cc: git@vger.kernel.org, gitster@pobox.com, jltobler@gmail.com,
johannes.schindelin@gmx.de, spectral@google.com
Subject: Re: [PATCH v3 1/3] clang-format: re-adjust line break penalties
Date: Mon, 14 Oct 2024 11:08:29 +0200 [thread overview]
Message-ID: <871q0jrr02.fsf@iotcl.com> (raw)
In-Reply-To: <74bbd2f9db1ddfd5210be8fde2db84f67acff27d.1728697428.git.karthik.188@gmail.com>
Karthik Nayak <karthik.188@gmail.com> 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
next prev parent reply other threads:[~2024-10-14 9:08 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-09 12:51 [PATCH 0/3] clang-format: fix rules to make the CI job cleaner Karthik Nayak
2024-10-09 12:55 ` [PATCH 1/3] clang-format: don't enforce the column limit Karthik Nayak
2024-10-09 15:45 ` Justin Tobler
2024-10-09 22:32 ` Junio C Hamano
2024-10-10 16:48 ` karthik nayak
2024-10-09 12:56 ` [PATCH 2/3] clang-format: don't align expressions after linebreaks Karthik Nayak
2024-10-09 12:56 ` [PATCH 3/3] clang-format: align consecutive macro definitions Karthik Nayak
2024-10-10 8:27 ` Toon Claes
2024-10-10 17:59 ` [PATCH v2 0/3] clang-format: fix rules to make the CI job cleaner Karthik Nayak
2024-10-10 17:59 ` [PATCH v2 1/3] clang-format: change column limit to 96 characters Karthik Nayak
2024-10-10 18:11 ` Kyle Lippincott
2024-10-10 19:49 ` karthik nayak
2024-10-10 20:09 ` Kyle Lippincott
2024-10-10 17:59 ` [PATCH v2 2/3] clang-format: don't align expressions after linebreaks Karthik Nayak
2024-10-10 17:59 ` [PATCH v2 3/3] clang-format: align consecutive macro definitions Karthik Nayak
2024-10-12 1:49 ` [PATCH v3 0/3] clang-format: fix rules to make the CI job cleaner Karthik Nayak
2024-10-12 1:49 ` [PATCH v3 1/3] clang-format: re-adjust line break penalties Karthik Nayak
2024-10-14 9:08 ` Toon Claes [this message]
2024-10-14 21:14 ` Taylor Blau
2024-10-15 11:35 ` karthik nayak
2024-10-15 11:20 ` karthik nayak
2024-10-14 20:59 ` Kyle Lippincott
2024-10-15 12:37 ` karthik nayak
2024-10-16 1:38 ` Kyle Lippincott
2024-10-16 21:17 ` karthik nayak
2024-10-12 1:49 ` [PATCH v3 2/3] clang-format: align consecutive macro definitions Karthik Nayak
2024-10-14 21:12 ` Kyle Lippincott
2024-10-15 7:57 ` karthik nayak
2024-10-12 1:49 ` [PATCH v3 3/3] clang-format: don't align expressions after linebreaks Karthik Nayak
2024-10-14 21:23 ` Kyle Lippincott
2024-10-15 11:17 ` karthik nayak
2024-10-18 8:46 ` [PATCH v4 0/2] Subject: clang-format: fix rules to make the CI job cleaner Karthik Nayak
2024-10-18 8:46 ` [PATCH v4 1/2] clang-format: re-adjust line break penalties Karthik Nayak
2024-10-25 2:37 ` Justin Tobler
2024-10-25 9:48 ` karthik nayak
2024-10-18 8:46 ` [PATCH v4 2/2] clang-format: align consecutive macro definitions Karthik Nayak
2024-10-18 21:37 ` [PATCH v4 0/2] Subject: clang-format: fix rules to make the CI job cleaner Taylor Blau
2024-10-20 11:17 ` karthik nayak
2024-10-21 21:48 ` Taylor Blau
2024-10-22 8:31 ` karthik nayak
2024-10-22 16:42 ` Taylor Blau
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=871q0jrr02.fsf@iotcl.com \
--to=toon@iotcl.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=jltobler@gmail.com \
--cc=johannes.schindelin@gmx.de \
--cc=karthik.188@gmail.com \
--cc=spectral@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.