Re: [PATCH] .clang-format: update column limit

[Alexander Potapenko <glider@google.com>]

Hi folks,

this came up in another code review
(https://lore.kernel.org/lkml/CAG_fn=WcrNqV4burBRPZZwoBLwgia7kerZ8g2vV5spzWF=houQ@mail.gmail.com/),
so I thought maybe it's time to revisit changing of ColumnLimit for clang-format?

I ran the script Joe provided, and there's a noticeable drift towards the longer lines in the past
three years:

 201789 78 87.16
 201579 79 87.77
 138155 80 88.19
  55886 81 88.35
  42656 82 88.48
  39539 83 88.60
  36490 84 88.71
  37856 85 88.83
  68131 86 89.03
  29352 87 89.12
  23277 88 89.19
  26902 89 89.27
  21405 90 89.34
  44506 91 89.47
  70788 92 89.69
  13416 93 89.73
  16650 94 89.78
  10872 95 89.81
   9786 96 89.84
  12170 97 89.88
   9139 98 89.90
   8516 99 89.93
   7008 100 89.95
   6058 101 89.97
   4692 102 89.98

At our team we try to run clang-format on all newly written code, which to great extent helps
to avoid style-related bikeshedding. I changed the local limit in my checkout and reflowed
mm/kmsan/*.c and mm/kfence/*.c, and they actually look better than before.

This is sure not enough to justify the 80->100 change, but as far as I can tell right now
reviewers are not actively paying attention at the lines that are shorter than 100 columns,
even if those exceed the 80-column limit. So even if all clang-format users switch to 100 columns
locally this wouldn't cause objections as long as checkpatch.pl is happy.
On the other hand, the readability of the code they produce is likely to increase.

Given that nothing changes for people who don't use clang-format, maybe having the limit conform
to what checkpatch.pl wants is not a bad idea after all?