From: Tejun Heo <tj@kernel.org>
To: Ingo Molnar <mingo@elte.hu>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
Linux Kernel <linux-kernel@vger.kernel.org>,
Yinghai Lu <yhlu.kernel@gmail.com>
Subject: Re: [GIT PULL] percpu fixes for 2.6.32-rc6
Date: Thu, 12 Nov 2009 19:58:19 +0900 [thread overview]
Message-ID: <4AFBEA4B.4070100@kernel.org> (raw)
In-Reply-To: <20091112103639.GB24684@elte.hu>
Hello, Ingo.
11/12/2009 07:36 PM, Ingo Molnar wrote:
>
> * Tejun Heo <tj@kernel.org> wrote:
>
>> Hmmm... The thing is that the nesting isn't that deep there and
>> breaking string in the middle is something we do quite often. What
>> checkpatch warning did you see?
>
> ( i did not run checkpatch over your commit - i just assumed that the
> ugliness was a checkpatch artifact. )
>
> Breaking strings mid-sentence is something we try not to do. (If you
> know about places that do it 'quite often' then those places need fixing
> too.)
Oh... I do that all the time and I see a lot of them around too.
> the git-grep comes up empty because the string was needlessly broken in
> mid-sentence. Which is a confusing result and which causes people to
> waste time trying to figure out where the message came from.
>
> The other messages in this function are fine btw, for example:
>
> git grep 'failed to populate'
>
> will come up with the right place.
While I agree this is a valid reason, I really don't think we should
be restructuring whole code to accomodate long strings on single line.
I think a better way would be to teach grepping tool to match those
broken lines. It shouldn't be too difficult to put this into ack[1]
and maybe we can have git-ack (that's a bad name for git tho). I'll
ask ack author nicely.
> ( There are also other reasons why we dont break strings mid-sentence -
> it's also less readable to have it on two lines. )
This really depends on personal tastes. When trying to use long
string literals, there are several choices.
1. Use broken strings.
printk("blah blah blah blah "
"blah blah blah blah\n");
2. Push it into new line and unindent it.
printk(
"blah blah blah blah blah blah blah blah\n");
3. Restructure code so that the literal ends up in outer block.
printk("blah blah blah blah blah blah blah blah\n");
I prefer the first choice. The third would be nice if it's trivial to
do but I don't think it should dictate the code structure. The second
one, I don't know. Some people like that and grep will be happy with
it but it just seems very disturbing to my eyes.
Thanks.
--
tejun
[1] http://betterthangrep.com/
next prev parent reply other threads:[~2009-11-12 10:57 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-11-10 6:04 [GIT PULL] percpu fixes for 2.6.32-rc6 Tejun Heo
2009-11-10 17:10 ` Linus Torvalds
2009-11-10 18:33 ` Tejun Heo
2009-11-10 18:54 ` Linus Torvalds
2009-11-10 19:25 ` Tejun Heo
2009-11-10 19:37 ` Ingo Molnar
2009-11-10 19:50 ` Tejun Heo
2009-11-10 21:42 ` Linus Torvalds
2009-11-11 3:55 ` Tejun Heo
2009-11-11 11:31 ` Ingo Molnar
2009-11-11 12:21 ` Tejun Heo
2009-11-11 19:57 ` Ingo Molnar
2009-11-12 10:11 ` Tejun Heo
2009-11-12 10:36 ` Ingo Molnar
2009-11-12 10:58 ` Tejun Heo [this message]
2009-11-12 11:25 ` Ingo Molnar
2009-11-12 14:26 ` Oliver Neukum
2009-11-12 15:17 ` Linus Torvalds
2009-11-12 15:30 ` Tejun Heo
2009-11-12 15:45 ` Tejun Heo
2009-11-12 15:52 ` Linus Torvalds
2009-11-12 17:04 ` Andres Baldrich
2009-11-12 17:18 ` Linus Torvalds
2009-11-12 18:04 ` Ingo Molnar
2009-11-12 18:14 ` Andi Kleen
2009-11-12 11:07 ` Ingo Molnar
2009-11-12 11:29 ` Tejun Heo
2009-11-11 8:49 ` [PATCH percpu#for-linus] percpu: restructure pcpu_extend_area_map() to fix bugs and improve readability Tejun Heo
2009-11-11 19:25 ` Linus Torvalds
2009-11-10 19:44 ` [GIT PULL] percpu fixes for 2.6.32-rc6 Tejun Heo
-- strict thread matches above, loose matches on Subject: below --
2009-11-13 3:53 Tejun Heo
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=4AFBEA4B.4070100@kernel.org \
--to=tj@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=torvalds@linux-foundation.org \
--cc=yhlu.kernel@gmail.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 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.