On Thu, Jun 11, 2020 at 6:22 PM Joe Perches <j...@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