Re: [PATCH v2 1/3] clang-format: change column limit to 96 characters

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Kyle Lippincott <spectral@xxxxxxxxxx> writes:

> On Thu, Oct 10, 2024 at 11:00 AM Karthik Nayak <karthik.188@xxxxxxxxx> 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 96 instead. This provides some slack so we
>> can ensure readability takes preference over the 80 character hard
>> limit.
>>
>> Signed-off-by: Karthik Nayak <karthik.188@xxxxxxxxx>
>> ---
>>  .clang-format | 5 ++++-
>>  1 file changed, 4 insertions(+), 1 deletion(-)
>>
>> diff --git a/.clang-format b/.clang-format
>> index 41969eca4b..684ab32d28 100644
>> --- a/.clang-format
>> +++ b/.clang-format
>> @@ -12,7 +12,10 @@ UseTab: Always
>>  TabWidth: 8
>>  IndentWidth: 8
>>  ContinuationIndentWidth: 8
>> -ColumnLimit: 80
>> +
>> +# While we recommend keeping column limit to 80, we want to also provide
>> +# some slack to maintain readability.
>> +ColumnLimit: 96
>>
>>  # C Language specifics
>>  Language: Cpp
>> --
>> 2.47.0
>>
>>
>
> I think this means that the next automated `clang-format` invocation
> will un-wrap lines that were wrapped at 80 columns (not characters)
> but fit in 96 columns. Modifying this setting and running
> `clang-format -i *.{c,h}` produces a lot of diffs of that kind. I
> don't think there's a way of setting a soft column limit in
> clang-format.

Ah! Good point.

> Personally, I'd be fine with a higher column limit, but we'd need to
> make a conscious change to the style guidelines for that.

With this, I would say that the best choice here would be to actually
set it to 0 like the previous version. So that we don't actually enforce
the column limit.

We could perhaps set the value here in the '.clang-format' to 0. While
also setting 'max_line_length = 95' in the '.editorconfig'. That would
mean that we don't enforce a width, but we nudge editors to wrap at 95
characters. Here contributors would still have the power to decide the
adequate width as needed.

Attachment: signature.asc
Description: PGP signature


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux