From: Marcel Holtmann <marcel@holtmann.org>
To: Johan Hedberg <johan.hedberg@gmail.com>
Cc: Felix Huber <felix.huber@schyf.de>, linux-bluetooth@vger.kernel.org
Subject: Re: Phonebook functions for BlueZ
Date: Mon, 08 Mar 2010 21:27:21 -0800 [thread overview]
Message-ID: <1268112441.3712.46.camel@localhost.localdomain> (raw)
In-Reply-To: <20100309033841.GA21210@jh-x301>
Hi Johan,
> > > > + if (g_str_equal(property, "direction")) {
> > > > + dbus_message_iter_get_basic(&sub, &direction);
> > > > + } else if (g_str_equal(property, "peer")) {
> > > > + dbus_message_iter_get_basic(&sub, &peer);
> > > > + vc->number = g_strdup(peer);
> > > > + } else if (g_str_equal(property, "reason")) {
> > > > + dbus_message_iter_get_basic(&sub, &reason);
> > > > + } else if (g_str_equal(property, "auxstatus")) {
> > > > + dbus_message_iter_get_basic(&sub, &auxstatus);
> > > > + } else if (g_str_equal(property, "line")) {
> > > > + dbus_message_iter_get_basic(&sub, &line);
> > > > + }
> > >
> > > No braces for one-line scopes.
> > Well, here we have a conflict: The kernel style guide says that if one
> > of the blocks has braces the other one should also have, even if it is a
> > single line.
>
> Yesh, I noticed the same thing when checking the kernel coding style
> guidelines. Most of BlueZ code is in conflict with the kernel coding
> style in this respect, so I think we'd need some comment from Marcel on
> what exactly he wants the BlueZ style to be (might be that I've already
> discussed this a long time ago with him but I can't remember the outcome
> right now).
there is not real rule here that can be followed and will be true in all
cases. As long as the code is easy to read and understand it is fine. It
goes more like this: If the else statement is by itself then don't
bother with braces around it. Even if the if needs braces. If you have
multiple else if then the braces are actually a good idea. I would
almost go that far for complex ones like the one above using braces
would make it less error prone if you change something later. Even if
the compiler actually does warn you these days.
Use your own personal judgment here. However if the reviewing the code
make my brain hurt, then you did it wrong ;)
Regards
Marcel
next prev parent reply other threads:[~2010-03-09 5:27 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-02-28 10:01 Phonebook functions for BlueZ Felix Huber
2010-03-01 19:20 ` Johan Hedberg
2010-03-07 17:15 ` Felix Huber
2010-03-09 3:38 ` Johan Hedberg
2010-03-09 5:27 ` Marcel Holtmann [this message]
2010-03-09 14:02 ` Stefan Seyfried
2010-03-09 16:58 ` Marcel Holtmann
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=1268112441.3712.46.camel@localhost.localdomain \
--to=marcel@holtmann.org \
--cc=felix.huber@schyf.de \
--cc=johan.hedberg@gmail.com \
--cc=linux-bluetooth@vger.kernel.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).