All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@lst.de>
To: Joe Perches <joe@perches.com>
Cc: Matthew Wilcox <willy@infradead.org>,
	Christoph Hellwig <hch@lst.de>,
	apw@canonical.com, Linus Torvalds <torvalds@linux-foundation.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-kernel@vger.kernel.org,
	linux-doc <linux-doc@vger.kernel.org>,
	Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
Subject: Re: [PATCH] checkpatch: make the line length warnings match the coding style document
Date: Tue, 22 Dec 2020 14:12:34 +0100	[thread overview]
Message-ID: <20201222131234.GA29028@lst.de> (raw)
In-Reply-To: <93a470c7631d2607e7b2a12e9cc5d8e930911989.camel@perches.com>

On Mon, Dec 21, 2020 at 08:08:20PM -0800, Joe Perches wrote:
> On Thu, 2020-12-10 at 13:27 -0800, Joe Perches wrote:
> > On Thu, 2020-12-10 at 20:09 +0000, Matthew Wilcox wrote:
> > > On Thu, Dec 10, 2020 at 12:05:04PM -0800, Joe Perches wrote:
> > > > Also, given the ever increasing average identifier length, strict
> > > > adherence to 80 columns is sometimes just not possible without silly
> > > > visual gymnastics.  The kernel now has quite a lot of 30+ character
> > > > length function names, constants, and structs.
> > > 
> > > maybe checkpatch should warn for identifiers that are 30+ characters
> > > long?  address the problem at its source ..
> > 
> > Hard to know when to warn as patches could just add uses of already
> > existing names and emitting warnings for those would just be annoying.
> > 
> > Maybe something that tests long identifier additions of
> > defines/functions/macros/structs but not their uses and maybe only
> > then in patches and not files.
> > 
> > Perhaps:
> 
> Anyone care that this should be added or not added to checkpatch?

It is pretty useless.  What we need is a patch that doesn't make people
uselessly add overly long lines against the intent of the coding style
document.  I have submitted a pretty reasonable one, and I'm open to
alternatives, but we need to to stop people submitting code that does
not fit the coding style all the time because checkpatch doesn't
complain.

  reply	other threads:[~2020-12-22 13:13 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-10  8:22 [PATCH] checkpatch: make the line length warnings match the coding style document Christoph Hellwig
2020-12-10 20:05 ` Joe Perches
2020-12-10 20:09   ` Matthew Wilcox
2020-12-10 21:27     ` Joe Perches
2020-12-22  4:08       ` Joe Perches
2020-12-22 13:12         ` Christoph Hellwig [this message]
2020-12-22 16:22           ` Joe Perches
2020-12-23  8:29             ` Christoph Hellwig

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=20201222131234.GA29028@lst.de \
    --to=hch@lst.de \
    --cc=akpm@linux-foundation.org \
    --cc=apw@canonical.com \
    --cc=joe@perches.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=miguel.ojeda.sandonis@gmail.com \
    --cc=torvalds@linux-foundation.org \
    --cc=willy@infradead.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.