lkml.org 
[lkml]   [2020]   [Jun]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [PATCH] .clang-format: update column limit
Hi Joe,

On Wed, Jun 10, 2020 at 7:13 PM Joe Perches <joe@perches.com> wrote:
>
> Ii think this is a not a good change.
>
> If you read the commit log you provided, it ways
> "staying withing 80 columns is certainly still _preferred_"

Yes, but the related email discussions were not about establishing a
new hard limit, but about avoiding such hard limits for
historical/technical reasons.

> With this change, clang would _always_ wrap to 100 columns.

That is true, but it means clang-format will start splitting lines in
weird ways because it has to work with whatever the code is without
changes. If a programmer sees that the lines are too long after
applying the formatter, then it is a strong hint the code needs to be
rearranged somehow (e.g. creating intermediate results).

Hence keeping the limit at 80 means we will get strange arrangements
which could have fit in 100 just fine. In fact, I would argue a
*wider* limit is better for an automatic formatter, e.g. 120. Even
more so considering clang-format is not responsible for the final
formatting -- at least not yet :-) -- the developer is.

Cheers,
Miguel

\
 
 \ /
  Last update: 2020-06-11 12:04    [W:0.126 / U:0.100 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site