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

From: Christian Brauner
Date: Wed Jun 10 2020 - 13:32:14 EST


On Wed, Jun 10, 2020 at 10:13:24AM -0700, Joe Perches wrote:
> On Wed, 2020-06-10 at 14:51 +0200, Christian Brauner wrote:
> > The provided clang-format file wraps at 80 chars. If noone minds I'd like
> > to adjust this limit to 100 similar to what checkpatch (cf. [1]) uses now.
> >
> > [1]: commit bdc48fa11e46 ("checkpatch/coding-style: deprecate 80-column warning")
> > Signed-off-by: Christian Brauner <christian.brauner@xxxxxxxxxx>
> []
> > diff --git a/.clang-format b/.clang-format
> []
> > @@ -52,7 +52,7 @@ BreakConstructorInitializersBeforeComma: false
> > #BreakConstructorInitializers: BeforeComma # Unknown to clang-format-4.0
> > BreakAfterJavaFieldAnnotations: false
> > BreakStringLiterals: false
> > -ColumnLimit: 80
> > +ColumnLimit: 100
>
> 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_"

I read it; that's why the "if noone minds" is there.

>
> With this change, clang would _always_ wrap to 100 columns.
>
> clang would not make any reasonable attempt to use 80 when
> it should.

You make it sounds like it caps all lines to 100 columns when really it
just does it for corner cases where we run over the 80 anwyways. I at
least don't regularly write lines of code that cross the 80 limit.
So when clang-format is called it's usually when something needs to be
reformatted at which point using the more lenient 100 char limit seems
sensible. But I don't particulary care about this patch. I can just
override the .clang-format file if this shakes the world too much.

Christian