From: Josh Triplett <josh@joshtriplett.org>
To: Joe Perches <joe@perches.com>
Cc: torvalds@linux-foundation.org, gregkh@linux-foundation.org,
Andy Whitcroft <apw@canonical.com>,
linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH] checkpatch: Make the 80-character limit a --strict check only
Date: Mon, 7 Oct 2013 19:08:14 -0700 [thread overview]
Message-ID: <20131008020814.GD6392@leaf> (raw)
In-Reply-To: <1381174700.2081.209.camel@joe-AO722>
On Mon, Oct 07, 2013 at 12:38:20PM -0700, Joe Perches wrote:
> On Mon, 2013-10-07 at 12:34 -0700, Josh Triplett wrote:
> > On Mon, Oct 07, 2013 at 12:28:26PM -0700, Joe Perches wrote:
> > > On Mon, 2013-10-07 at 12:18 -0700, Josh Triplett wrote:
> > > > The 80-character limit is not a hard-and-fast rule, nor should it be
> > > > applied blindly by people running checkpatch and fixing its warnings.
> > > > Sometimes it's better to violate the 80-character "limit" in the name of
> > > > readability, and when it isn't, it's often better to refactor into a
> > > > function or otherwise restructure the code rather than just finding
> > > > increasingly awkward places to break lines.
> > > >
> > > > Thus, change checkpatch's LONG_LINE warning to a --strict CHK instead.
> > > > Anyone wanting to use checkpatch to check for this can easily enough
> > > > enable --strict or turn on LONG_LINE explicitly, but it shouldn't be
> > > > part of the default warnings.
> > >
> > > I don't agree with this.
> > >
> > > CodingStyle says:
> > > ----------------------
> > > The limit on the length of lines is 80 columns and this is a strongly
> > > preferred limit.
> > > ----------------------
> >
> > Which is the subject of much controversy and extensive discussion, and
> > the consensus on the list (including by many maintainers) frequently
> > differs from that.
>
> Been there, had that discussion.
> https://lkml.org/lkml/2009/12/18/3
I see many positive responses in that thread, from Linus and others, and
very little negativity (mostly quibbles about implementation, not about
the overall proposal). What was the problem?
In particular:
> I'll happily remove the checkpatch.pl limit entirely, and ask people to
> try to use common sense, though.
Between that and the positive responses in this thread, I'd love to see
your proposed patch revived.
- Josh Triplett
next prev parent reply other threads:[~2013-10-08 2:08 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-07 19:18 [RFC PATCH] checkpatch: Make the 80-character limit a --strict check only Josh Triplett
2013-10-07 19:28 ` Joe Perches
2013-10-07 19:34 ` Josh Triplett
2013-10-07 19:38 ` Joe Perches
2013-10-08 2:08 ` Josh Triplett [this message]
2013-10-07 21:23 ` Al Viro
2013-10-07 21:33 ` Joe Perches
2013-10-07 21:41 ` Joe Perches
2013-10-07 19:50 ` Richard Weinberger
2013-10-07 21:40 ` Andi Kleen
2013-10-08 4:13 ` Greg KH
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=20131008020814.GD6392@leaf \
--to=josh@joshtriplett.org \
--cc=apw@canonical.com \
--cc=gregkh@linux-foundation.org \
--cc=joe@perches.com \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@linux-foundation.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.