From: Joe Perches <joe@perches.com>
To: Linus Torvalds <torvalds@linux-foundation.org>,
git <git@vger.kernel.org>, Junio C Hamano <gitster@pobox.com>
Cc: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>,
Petr Mladek <pmladek@suse.com>,
Geert Uytterhoeven <geert@linux-m68k.org>,
Steven Rostedt <rostedt@goodmis.org>,
Mark Rutland <mark.rutland@arm.com>,
Andrew Morton <akpm@linux-foundation.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] printk: Remove no longer used second struct cont
Date: Thu, 15 Dec 2016 18:30:46 -0800 [thread overview]
Message-ID: <1481855446.29291.80.camel@perches.com> (raw)
In-Reply-To: <CA+55aFxaOFoh+Zrm5tNhU4hWu4Z032+nqV3vXK=QPJyhZsU3_A@mail.gmail.com>
On Thu, 2016-12-15 at 18:10 -0800, Linus Torvalds wrote:
> On Thu, Dec 15, 2016 at 5:57 PM, Joe Perches <joe@perches.com> wrote:
> > >
> > > In fact, I thought we already upped the check-patch limit to 100?
> >
> > Nope, CodingStyle neither.
> >
> > Last time I tried was awhile ago.
>
> Ok, it must have been just talked about, and with the exceptions for
> strings etc I may not have seen as many of the really annoying line
> breaks lately.
>
> I don't mind a 80-column "soft limit" per se: if some code
> consistently goes over 80 columns, there really is something seriously
> wrong there. So 80 columns may well be the right limit for that kind
> of check (or even less).
Newspaper column widths were relatively small for a good reason.
I think most of the uses of simple statements should be on a single
line. I'd rather see just a few arguments on a single line than a
dozen though. Especially those with long identifiers, functions
with many arguments are just difficult to visually scan.
> But if we have just a couple of lines that are longer (in a file that
> is 3k+ lines), I'd rather not break those.
>
> I tend use "git grep" a lot, and it's much easier to see function
> argument use if it's all on one line.
>
> Of course, some function calls really are *so* long that they have to
> be broken up, but that's where the "if it's a couple of lines that go
> a bit over the 80 column limit..." exception basically comes in.
>
> Put another way: long lines definitely aren't good. But breaking long
> lines has some downsides too, so there should be a balance between the
> two, rather than some black-and-white limit.
>
> In fact, we've seldom had cases where black-and-white limits work well.
One thing that _would_ be useful is some enhancement to git grep
that would look for multi-line statements more easily.
The git grep -P option doesn't span lines.
grep 2.5.4 was the last version that supported the -P option to
grep through for multiple lines.
It'd be nice to have something like
git grep --code_style=c90 --function <foo>
that'd show all multiple line uses/definitions/declarations of a
particular function.
I played with extending git grep a bit once, mostly to get the \s
mechanism to span lines. It kinda worked.
Still, it seems like real work to implement well.
next parent reply other threads:[~2016-12-16 2:41 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1481806438-30185-1-git-send-email-geert@linux-m68k.org>
[not found] ` <20161215162336.GA18152@pathway.suse.cz>
[not found] ` <20161216013706.GA20445@jagdpanzerIV.localdomain>
[not found] ` <CA+55aFz3B2BfjG54z7ALOwezCHSdQp+YbFaHcJkCg=fzoKtfNg@mail.gmail.com>
[not found] ` <1481853432.29291.76.camel@perches.com>
[not found] ` <CA+55aFxaOFoh+Zrm5tNhU4hWu4Z032+nqV3vXK=QPJyhZsU3_A@mail.gmail.com>
2016-12-16 2:30 ` Joe Perches [this message]
2016-12-16 5:00 ` [PATCH] printk: Remove no longer used second struct cont Junio C Hamano
2016-12-16 6:04 ` 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=1481855446.29291.80.camel@perches.com \
--to=joe@perches.com \
--cc=akpm@linux-foundation.org \
--cc=geert@linux-m68k.org \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=pmladek@suse.com \
--cc=rostedt@goodmis.org \
--cc=sergey.senozhatsky.work@gmail.com \
--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 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).