Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <20200610125147.2782142-1-christian.brauner@ubuntu.com>
 <c8851256aa453461481233e8a7fea878f9580c5b.camel@perches.com>
 <CANiq72=BbGqXmiG8+1QuJnLXMTwNjUg9WuWR9eJcLMHZ=k5hQw@mail.gmail.com>
 <4c6f8d63817cbc51765fd0b3046f81dccbd17ec7.camel@perches.com>
 <CANiq72nOaDo9LQ3JoZk6VH-ZYErHpvD1O=DyVngs3xno5e9W7Q@mail.gmail.com> <b4646ed22573568c0953d272514ab3b701e54faa.camel@perches.com>
In-Reply-To: <b4646ed22573568c0953d272514ab3b701e54faa.camel@perches.com>
From:   Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
Date:   Thu, 11 Jun 2020 20:51:16 +0200
Message-ID: <CANiq72=58t3T0VckOOm7jAnwaxdEK2zbrWeQw-bXifmOq86BCA@mail.gmail.com>
Subject: Re: [PATCH] .clang-format: update column limit
To:     Joe Perches <joe@perches.com>
Cc:     Christian Brauner <christian.brauner@ubuntu.com>,
        linux-kernel <linux-kernel@vger.kernel.org>,
        clang-built-linux <clang-built-linux@googlegroups.com>,
        Linus Torvalds <torvalds@linux-foundation.org>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Thu, Jun 11, 2020 at 6:22 PM Joe Perches <joe@perches.com> wrote:
>
> On Thu, 2020-06-11 at 13:54 +0200, Miguel Ojeda wrote:
> > Why is 80 "still preferred" to begin with?
>
> That's neither my nor your issue to solve.

? You (or Linus, I still don't know since the commit is on your name
but I can't find the full patch in the list...) updated the wording on
`coding-style.rst` and I have to decide what limit to put into
`ColumnLimit` to make `clang-format` most useful for developers within
the new constraints. So it does concern us...

In my view, `coding-style.rst` is saying what it used to say from the
point of view of a new contributor. But regardless of that, forcing
`clang-format` to work under the 80-column constraint means we will
get code that won't look as good as giving it a slightly higher hard
limit. Yes, more lines will get over 80, but that is not as big of a
concern now since it is not as "strongly preferred" as before, which
is the point I was trying to make.

A concern for keeping the `clang-format` limit as it is that I can
think of is that newcomers using `clang-format` may feel forced not to
go over 80-column no matter what since "that is what the tool does".
On the other hand, my concern for *increasing* it is about things like
function signatures, since there is no easy way to decrease their
length or rearrange them without reducing the identifiers' length. A
third alternative is using `ColumnWidth: 0` and let people break lines
on their own, `clang-format` will respect that if possible. But then
we rely on people using `checkpatch` and they have to take care of the
limit themselves, so the advantage of automatic formatting decreases.

By the way, I noticed that a lot of kernel code will still trigger the
100-column warning (~20% of the previous set triggering it!).

Cheers,
Miguel