From: Matthew Dobson <colpatch@us.ibm.com>
To: Ingo Oeser <ioe-lkml@rameria.de>
Cc: linux-kernel@vger.kernel.org, kernel-janitors@lists.osdl.org,
manfred@colorfullife.com, Pekka J Enberg <penberg@cs.helsinki.fi>
Subject: Re: [PATCH 6/9] Cleanup kmem_cache_create()
Date: Fri, 11 Nov 2005 10:28:41 -0800 [thread overview]
Message-ID: <4374E2D9.3020304@us.ibm.com> (raw)
In-Reply-To: <200511110910.38350.ioe-lkml@rameria.de>
Ingo Oeser wrote:
> On Friday 11 November 2005 01:04, Matthew Dobson wrote:
>
>>- if (size < 4096 || fls(size - 1) == fls(size - 1 + 3 * BYTES_PER_WORD))
>>+ if (size < RED_ZONE_LIMIT ||
>>+ fls(size - 1) == fls(size - 1 + 3 * BYTES_PER_WORD))
>> flags |= SLAB_RED_ZONE|SLAB_STORE_USER;
>
>
> I would suggest sth. like
>
> if (size < RED_TONE_LIMIT
> || fls(size - 1) = fls(size - 1 + 3 * BYTES_PER_WORD))
> flags |= SLAB_RED_ZONE | SLAB_STORE_USER
>
>
> Reason: A binary operator in front is a huge hint
> that this is a continued line.
>
> Just compare when you go to a store next time.
>
> 1
> + 2
> - 3
> * 4
>
> is much more readable then
>
> 1 +
> 2 -
> 3 *
> 4
>
> right?
>
>
> Regards
>
> Ingo Oeser
You make a very good point. It's not the way that I'm used to writing
multi-line ifs, but it is a bit more readable. However, since the rest of
the multi-line ifs in the file have the binary operator at the end of the
first line, I'm inclined to leave it the way it is for consistency. If
anyone really feels strongly, I could come up with a patch for the whole
file...?
Thanks for the feedback!
-Matt
next prev parent reply other threads:[~2005-11-11 18:28 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-11-10 23:53 [PATCH 0/9] Cleanup mm/slab.c v2 Matthew Dobson
2005-11-10 23:56 ` [PATCH 1/9] CodingStyle-ify mm/slab.c Matthew Dobson
2005-11-10 23:58 ` [PATCH 2/9] Use 'nid' Matthew Dobson
2005-11-13 20:15 ` Pavel Machek
2005-11-10 23:59 ` [PATCH 3/9] Fix alloc_percpu's args Matthew Dobson
2005-11-11 0:01 ` [PATCH 4/9] Create helper for /proc/slabinfo Matthew Dobson
2005-11-11 0:03 ` [PATCH 5/9] Create helper for kmem_cache_create() Matthew Dobson
2005-11-11 0:04 ` [PATCH 6/9] Cleanup kmem_cache_create() Matthew Dobson
2005-11-11 8:10 ` Ingo Oeser
2005-11-11 18:28 ` Matthew Dobson [this message]
2005-11-11 0:05 ` [PATCH 7/9] Cleanup cache_reap() Matthew Dobson
2005-11-11 0:06 ` [PATCH 8/9] Cleanup slabinfo_write() Matthew Dobson
2005-11-11 0:07 ` [PATCH 9/9] Cleanup a loop in set_slab_attr() Matthew Dobson
2005-11-11 7:29 ` [PATCH 0/9] Cleanup mm/slab.c v2 Pekka J Enberg
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=4374E2D9.3020304@us.ibm.com \
--to=colpatch@us.ibm.com \
--cc=ioe-lkml@rameria.de \
--cc=kernel-janitors@lists.osdl.org \
--cc=linux-kernel@vger.kernel.org \
--cc=manfred@colorfullife.com \
--cc=penberg@cs.helsinki.fi \
/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