Re: [PATCH 1/3] clang-format: don't enforce the column limit
- From
karthik nayak <karthik.188@gmail.com>
- Date
- Oct 10, 2024, 16:48 UTC
- Message-ID
- <CAOLa=ZRRHYwe7=aJogL0=R8SHyPkHeC7C34R3mkR-gmzkRQ9JA@mail.gmail.com>
- In-Reply-To
- <xmqqttdkoqks.fsf@gitster.g>
Junio C Hamano <gitster@pobox.com> writes:
Show 17 quoted lines
> Justin Tobler <jltobler@gmail.com> writes: > >> On 24/10/09 05:55AM, Karthik Nayak wrote: >>> The current value for the column limit is set to 80. While this is as >>> expected, we often prefer readability over this strict limit. This means >>> it is common to find code which extends over 80 characters. So let's >>> change the column limit to be 0 instead. This ensures that the formatter >>> doesn't complain about code strictly not following the column limit. >> >> The column limit does lead to quite a few false positives. At the same >> time though, in some ways having a tool point out all the instances it >> occurs does make it easier to review if any should be addressed. >> >> If the goal is to have a CI job that we generally expect to pass, then >> it makes sense to remove it. I don't feel super strongly either way. > Is it possible for gatekeeper jobs to complain only on newly added > violations?
The CI job is indeed only checking the newly added code. We do this using 'git clang-format' which takes in the basecommit as a param. This is in 'ci/run-style-check.sh'.
> Then it is fine to have a limit with a bit of slack, > say like 96 columns (with 16-column readability slack).
This is a good idea. Let me add change this in the next version.