From: Philippe Gerum <rpm@xenomai.org>
To: dietmar.schindler@domain.hid
Cc: xenomai@xenomai.org
Subject: Re: [Xenomai-help] message pipe message boundaries
Date: Wed, 11 May 2011 13:02:06 +0200 [thread overview]
Message-ID: <1305111726.2098.30.camel@domain.hid> (raw)
In-Reply-To: <1183078C0D064042B3AD2D03E3859EF179C957@domain.hid>
On Wed, 2011-05-11 at 12:48 +0200, dietmar.schindler@domain.hid
wrote:
> > From: Philippe Gerum [mailto:rpm@xenomai.org]
> > Sent: Wednesday, May 11, 2011 11:21 AM
> > ...
> > Also, let's avoid constructs like these:
> >
> > > buf = iovec->iov_base, count = iovec++->iov_len;
> >
> > Disk space is cheap so we can afford a few more characters per line;
> > ...
>
> Could you please explain what you mean by this? I can imagine to put a few more characters into the line above by changing it to
>
> buf = iovec->iov_base, count = iovec->iov_len, ++iovec;
>
> but this would seem to contradict your recommendation below.
buf = iovec->iov_base;
count = iovec->iov_len;
++iovec;
One exec statement per line, no comma operator, no combined
post-incrementation and dereference to obfuscate the obvious, because we
don't care about a few more characters in the source code: we do want
readability. Plain, silly, massively non-imaginative obviousness of
constructs.
>
> > In short, one executable statement per line is desired, our code should
> > have nothing to hide.
>
> Since the above code line contains only one statement, I assume you mean one assignment-expression, and will do accordingly.
>
> By the way, what is your convention regarding goto?
Absolutely fine to use it for handling error paths sanely without code
duplication, and anywhere it would spare us weird games based on
obfuscated variable updates and tests only to control the code flow.
--
Philippe.
next prev parent reply other threads:[~2011-05-11 11:02 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-04-26 9:48 [Xenomai-help] message pipe message boundaries dietmar.schindler
2011-04-26 20:27 ` Philippe Gerum
2011-04-27 8:50 ` dietmar.schindler
2011-04-27 12:22 ` dietmar.schindler
2011-04-27 21:42 ` Philippe Gerum
2011-04-29 6:30 ` dietmar.schindler
2011-05-03 8:15 ` dietmar.schindler
2011-05-03 11:00 ` Gilles Chanteperdrix
2011-05-03 11:27 ` dietmar.schindler
2011-05-03 17:35 ` Gilles Chanteperdrix
2011-05-04 6:36 ` dietmar.schindler
2011-05-04 6:40 ` Gilles Chanteperdrix
2011-05-04 14:34 ` dietmar.schindler
2011-05-05 8:14 ` Gilles Chanteperdrix
2011-05-09 7:36 ` dietmar.schindler
2011-05-11 9:12 ` Gilles Chanteperdrix
2011-05-11 9:20 ` Philippe Gerum
2011-05-11 10:48 ` dietmar.schindler
2011-05-11 10:55 ` Gilles Chanteperdrix
2011-05-11 11:02 ` Philippe Gerum [this message]
2011-05-19 13:09 ` dietmar.schindler
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=1305111726.2098.30.camel@domain.hid \
--to=rpm@xenomai.org \
--cc=dietmar.schindler@domain.hid \
--cc=xenomai@xenomai.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 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.