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 12:34:33 -0700 [thread overview]
Message-ID: <20131007193433.GF13643@jtriplet-mobl1> (raw)
In-Reply-To: <1381174106.2081.207.camel@joe-AO722>
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.
> People should be encouraged to use 80 column lines and as well
> should learn to ignore messages they don't agree with.
I've seen far more examples of the 80-column limit making code less
readable rather than more. It's only really helpful when it forces code
restructuring, *not* when it just forces an arbitrary line break.
> If people are using checkpatch prior to any scripted git am,
> then just as easily they could add --ignore=LONG_LINE.
Which random folks running checkpatch on staging drivers and trying to
help don't necessarily know to do. The defaults should cater to the
primary use case, and the 80-column limit is not something to apply
blindly. It falls in the same category as some of the warnings the
kernel emits with W=2 or so: sometimes helpful, often noise.
- Josh Triplett
next prev parent reply other threads:[~2013-10-07 19:34 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 [this message]
2013-10-07 19:38 ` Joe Perches
2013-10-08 2:08 ` Josh Triplett
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=20131007193433.GF13643@jtriplet-mobl1 \
--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.