From: Joe Perches <joe@perches.com>
To: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>,
Ansuel Smith <ansuelsmth@gmail.com>
Cc: Nathan Chancellor <nathan@kernel.org>,
Miguel Ojeda <ojeda@kernel.org>,
Nick Desaulniers <ndesaulniers@google.com>,
linux-kernel <linux-kernel@vger.kernel.org>,
clang-built-linux <clang-built-linux@googlegroups.com>
Subject: Re: [PATCH] clang-format: Update ColumnLimit
Date: Fri, 19 Mar 2021 21:56:02 -0700 [thread overview]
Message-ID: <03d462504887401ffbcdb58a392ad01923a2be7b.camel@perches.com> (raw)
In-Reply-To: <CANiq72=sEtv6-uMqY5QqpHSEqZnMj=6VrhgyFE2a=wZy=+_SEQ@mail.gmail.com>
On Fri, 2021-03-19 at 19:48 +0100, Miguel Ojeda wrote:
> On Fri, Mar 19, 2021 at 7:45 PM Ansuel Smith <ansuelsmth@gmail.com> wrote:
> >
> > Sorry, didn't notice that. Considering that checkpatch complains and
> > some reviewers actually state that 100 is the new limit, I think it's
> > time to update the file.
>
> IIUC, 80 is still the soft limit, but 100 is now the hard limit.
80 columns is still the strongly preferred limit.
From coding-style.rst:
-------------------------------
The preferred limit on the length of a single line is 80 columns.
Statements longer than 80 columns should be broken into sensible chunks,
unless exceeding 80 columns significantly increases readability and does
not hide information.
-------------------------------
IMO: clang-format is mechanical and, like checkpatch, doesn't have much
'taste'.
Ideally, 100 columns would only be used when long length identifiers
exist with some mechanism that determines statement complexity.
Today it's fairly easy to go beyond 80 columns even if a statement
is similar to
a = b + c;
when identifier lengths are relatively long.
There are many existing 25+ character length identifiers, so the trivial
statement above if used with all identifiers of 25 characters or more
exceeds 80 columns.
So for some things, clang-format (and checkpatch) should allow > 80 column
lines for trivial statements like the above.
It's not a trivial implementation problem though.
prev parent reply other threads:[~2021-03-20 5:25 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-19 18:37 [PATCH] clang-format: Update ColumnLimit Ansuel Smith
2021-03-19 18:42 ` Nathan Chancellor
2021-03-19 18:45 ` Ansuel Smith
2021-03-19 18:48 ` Miguel Ojeda
2021-03-20 4:56 ` Joe Perches [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=03d462504887401ffbcdb58a392ad01923a2be7b.camel@perches.com \
--to=joe@perches.com \
--cc=ansuelsmth@gmail.com \
--cc=clang-built-linux@googlegroups.com \
--cc=linux-kernel@vger.kernel.org \
--cc=miguel.ojeda.sandonis@gmail.com \
--cc=nathan@kernel.org \
--cc=ndesaulniers@google.com \
--cc=ojeda@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.