linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Joe Perches <joe@perches.com>
To: "Luck, Tony" <tony.luck@intel.com>,
	"Levin, Alexander" <alexander.levin@verizon.com>
Cc: 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 11:01:40 -0700	[thread overview]
Message-ID: <1472493700.3425.67.camel@perches.com> (raw)
In-Reply-To: <3908561D78D1C84285E8C5FCA982C28F3A1B3222@ORSMSX114.amr.corp.intel.com>

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,
but I see that submitted by some names I haven't seen
before all the time.

It's not an easy problem to solve with regexes though.

> FWIW I do find checkpatch is helpful enough with useful tips
> that it has value even when it generates some noise. Generally
> the better you are at conforming to kernel style, the more irritating
> it will be, because you only see the questionable output. For
> newbies, and less frequent contributors (especially those who
> work on other projects with other style guides) it is likely still
> doing a good job.
> 
> In the journey from 4.6 to 4.7 we had 13433 commits. 2258 (16%)
> from people with 5 or fewer commits in that release. Those are
> the people most helped by checkpatch (plus the maintainers who
> took those patches didn't have to spend as many cycles complaining
> about style).
> 
> I think the bottom line is whether checkpatch's helpful messages do
> more good than the grey area messages that cause people to make
> questionable changes to shut checkpatch up.
> 
> -Tony

  reply	other threads:[~2016-08-29 18:01 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 [this message]
2016-08-29 18:47             ` Joe Perches
2016-08-29 19:08             ` Josh Triplett
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=1472493700.3425.67.camel@perches.com \
    --to=joe@perches.com \
    --cc=alexander.levin@verizon.com \
    --cc=gregkh@linuxfoundation.org \
    --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).