From: Oleg Goldshmidt <pub@goldshmidt.org>
To: harry <harry@hebutterworth.freeserve.co.uk>
Cc: xen-devel@lists.xensource.com,
Vincent Hanquez <vincent.hanquez@cl.cam.ac.uk>
Subject: Re: USB virt 2.6 split driver patch series
Date: 21 Nov 2005 17:26:50 +0000 [thread overview]
Message-ID: <m3br0d52ud.fsf@goldshmidt.org> (raw)
In-Reply-To: <1132581661.31295.134.camel@localhost.localdomain>
harry <harry@hebutterworth.freeserve.co.uk> writes:
> I have read Documentation/CodingStyle quite carefully and there is no
> mention of using braces inside functions. I'm used to using braces to
> define minimal scopes for local variables which makes the code easier to
> read by minimising the number of variables you need to keep track of
> when reading it and by declaring variables closer to where they are used
> so it is easier to verify that they have been correctly initialised.
>
> Is this really banned?
Not explicitly, but:
1) It increases the number of almost empty lines, which is explicitly
frowned upon. An opening brace in an empty line by itself is
allowed in the beginning of a function body, as per K&R style, and
it is an exception.
2) It deepens block nesting, which is also explicitly frowned upon.
3) CodingStyle explicitly says that the number of local variables in a
function should be small (over 5-10 and you are in trouble as far
as both style and design are concerned). This is a corollary to the
rule that a function should do one thing and one thing only (but do
it well). If you follow this rule then introducing blocks to limit
variable scope is never really justified. If you find yourself in a
situation where you need such blocking then maybe you should think
of more modularization (at the function level). Disclaimer: I have
not studied the patches attentively enough to suggest that you need
this.
Another style comment that I have is that I think that
struct xenidc_channel_struct {
void (*submit_message)
(xenidc_channel * channel, xenidc_channel_message * message);
is inferior to
struct xenidc_channel_struct {
void (*submit_message)(xenidc_channel * channel,
xenidc_channel_message * message);
in terms of readability.
--
Oleg Goldshmidt | pub@NOSPAM.goldshmidt.org | http://www.goldshmidt.org
next prev parent reply other threads:[~2005-11-21 17:26 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-11-21 13:18 USB virt 2.6 split driver patch series harry
2005-11-21 13:49 ` Vincent Hanquez
2005-11-21 14:01 ` harry
2005-11-21 14:27 ` Vincent Hanquez
2005-11-21 14:29 ` Dave Feustel
2005-11-21 14:41 ` NAHieu
2005-11-21 15:14 ` harry
2005-11-21 15:27 ` NAHieu
2005-11-21 15:39 ` harry
2005-11-21 17:02 ` NAHieu
2005-11-21 17:17 ` harry
2005-11-22 1:59 ` NAHieu
2005-11-22 2:00 ` NAHieu
2005-11-22 10:24 ` harry
2005-11-22 11:07 ` Vincent Hanquez
2005-11-22 15:37 ` Anthony Liguori
2005-11-22 20:27 ` Vincent Hanquez
2005-11-21 15:44 ` Muli Ben-Yehuda
2005-11-21 18:49 ` Harry Butterworth
2005-11-21 18:58 ` Muli Ben-Yehuda
2005-11-25 19:16 ` harry
2005-11-21 17:26 ` Oleg Goldshmidt [this message]
2005-11-21 15:34 ` harry
2005-11-21 14:25 ` Dave Feustel
2005-11-21 14:36 ` Vincent Hanquez
2005-11-21 15:24 ` Dave Feustel
2005-11-21 16:03 ` Vincent Hanquez
2005-11-21 16:30 ` Dave Feustel
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=m3br0d52ud.fsf@goldshmidt.org \
--to=pub@goldshmidt.org \
--cc=harry@hebutterworth.freeserve.co.uk \
--cc=vincent.hanquez@cl.cam.ac.uk \
--cc=xen-devel@lists.xensource.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.