From: Josh Triplett <josh@joshtriplett.org>
To: Joe Perches <joe@perches.com>
Cc: "Luck, Tony" <tony.luck@intel.com>,
"Levin, Alexander" <alexander.levin@verizon.com>,
Greg KH <gregkh@linuxfoundation.org>,
Sasha Levin <levinsasha928@gmail.com>,
"ksummit-discuss@lists.linuxfoundation.org"
<ksummit-discuss@lists.linuxfoundation.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [Ksummit-discuss] checkkpatch (in)sanity ?
Date: Mon, 29 Aug 2016 12:08:16 -0700 [thread overview]
Message-ID: <20160829190816.GA27600@cloud> (raw)
In-Reply-To: <1472493700.3425.67.camel@perches.com>
On Mon, Aug 29, 2016 at 11:01:40AM -0700, Joe Perches wrote:
> On Mon, 2016-08-29 at 17:46 +0000, Luck, Tony wrote:
> > >
> > > 80 columns is simply silly when dealing with either
> > > long identifiers or many levels of indentation.
> > >
> > > One thing that 80 column limit does do is encourage
> > > shorter identifiers and fewer levels of indentation.
> > >
> > > Generally, both of those are good things.
> > I think the main complaint with the limit is that people fix it by simply
> > breaking the long line, which often makes for less readable code.
> >
> > Perhaps there would be less pushback on this if checkpatch also
> > complained about clumsily broken long lines and offered the advice
> > to restructure the code with helper functions etc. to avoid deep
> > indentation?
>
> It suggests that already for 6+ leading tabs, but some more
> intelligence for nominally ugly added line breaks would
> definitely help.
>
> Using longish simple identifiers or multiple dereferences
> can make the line breaks at 80 columns silly.
>
> Simple things like:
>
> if (longish_identifier != AN_EVEN_LONGER_DEFINED_CONSTANT_VALUE)
> and
> if (some_pointer->member[index].another_member >> shift_constant)
>
> shouldn't really ever be broken into multiple lines,
Agreed.
Honestly, I almost never see a line that should break solely based on
length. Almost any line that makes sense to break at a given point
would make sense to break at that point even with a target line length
of 200.
For instance:
if (an_interesting_function(x) == TARGET_VALUE_FOR_X
|| an_interesting_function(y) == TARGET_VALUE_FOR_Y) {
That line break makes sense whether you want to break lines at 80
characters, 100, or 800. (You could argue about
before-or-after-operator, or about line alignment.) In almost no
circumstances would you want to also break around the '==', even though
that second line takes up 82 characters.
next prev parent reply other threads:[~2016-08-29 19:08 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-27 20:40 checkkpatch (in)sanity ? Joe Perches
2016-08-28 1:06 ` Levin, Alexander
2016-08-28 1:42 ` Joe Perches
2016-08-28 2:20 ` Joe Perches
2016-08-28 2:47 ` Levin, Alexander
2016-08-28 17:15 ` Joe Perches
2016-08-28 17:59 ` Greg KH
2016-08-28 22:37 ` Levin, Alexander
2016-08-28 23:20 ` Joe Perches
2016-08-29 2:22 ` Levin, Alexander
2016-08-29 8:20 ` Christoph Hellwig
2016-08-29 7:15 ` [Ksummit-discuss] " Alexandre Belloni
2016-08-29 9:01 ` Arnd Bergmann
2016-08-29 12:47 ` Joe Perches
2016-08-29 17:16 ` Josh Triplett
2016-08-29 17:41 ` Joe Perches
2016-08-29 17:46 ` Luck, Tony
2016-08-29 18:01 ` Joe Perches
2016-08-29 18:47 ` Joe Perches
2016-08-29 19:08 ` Josh Triplett [this message]
2016-08-29 21:07 ` Arnd Bergmann
2016-08-29 11:15 ` Kalle Valo
2016-08-29 12:30 ` Joe Perches
2016-08-29 18:01 ` Kalle Valo
2016-08-29 19:00 ` Joe Perches
2016-08-29 21:00 ` [Ksummit-discuss] " Arnd Bergmann
2016-08-28 7:56 ` Alexey Dobriyan
2016-08-28 9:59 ` Julia Lawall
2016-08-28 19:52 ` Joe Perches
2016-08-28 20:35 ` Jiri Kosina
2016-08-28 21:24 ` Dennis Kaarsemaker
2016-08-28 21:57 ` Joe Perches
2016-08-29 19:06 ` Dan Carpenter
2016-08-29 19:10 ` Josh Triplett
2016-08-29 19:17 ` Dan Carpenter
2016-08-29 19:34 ` Joe Perches
2016-08-29 19:21 ` Joe Perches
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=20160829190816.GA27600@cloud \
--to=josh@joshtriplett.org \
--cc=alexander.levin@verizon.com \
--cc=gregkh@linuxfoundation.org \
--cc=joe@perches.com \
--cc=ksummit-discuss@lists.linuxfoundation.org \
--cc=levinsasha928@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=tony.luck@intel.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).