[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH] CODING_STYLE: don't allow non-indented statemen
From: |
Aurelien Jarno |
Subject: |
Re: [Qemu-devel] [PATCH] CODING_STYLE: don't allow non-indented statements after if/else blocks |
Date: |
Mon, 26 Oct 2009 21:27:07 +0100 |
User-agent: |
Mutt/1.5.18 (2008-05-17) |
On Mon, Oct 26, 2009 at 10:20:34PM +0200, Blue Swirl wrote:
> On Mon, Oct 26, 2009 at 10:03 PM, Aurelien Jarno <address@hidden> wrote:
> > On Mon, Oct 26, 2009 at 06:02:52PM +0200, Blue Swirl wrote:
> >> On Mon, Oct 26, 2009 at 8:26 AM, Aurelien Jarno <address@hidden> wrote:
> >> > Rationale: The following code is difficult to read, but allowed by the
> >> > current coding style.
> >>
> >> Fully agree.
> >>
> >> > +Every control flow statement is followed by a new indented and braced
> >> > +block; even if the block contains just one statement. The opening brace
> >> > +is on the line that contains the control flow statement that introduces
> >> > +the new block; the closing brace is on the same line as the else
> >> > keyword,
> >> > +or on a line by itself if there is no else keyword. Example:
> >>
> >> I think an exception should be granted for "else if" case, otherwise
> >> the style would require braces around "if", like:
> >> if (a == 5) {
> >> printf("a was 5.\n");
> >> } else {
> >> if (a == 6) {
> >> printf("a was 6.\n");
> >> }
> >> } else {
> >> printf("a was something else entirely.\n");
> >> }
> >>
> >> Picking nits: "while" is a control flow statement, even in "do {}
> >> while" statement and then it would illegal to require a braced block
> >> after the "while" statement.
> >
> > Good point. Please find another try below:
> >
> > From: Aurelien Jarno <address@hidden>
> >
> > Rationale: The following code is difficult to read:
> >
> > if (a == 5) printf("a was 5.\n");
> > else if (a == 6) printf("a was 6.\n");
> > else printf("a was something else entirely.\n");
> >
> > Signed-off-by: Aurelien Jarno <address@hidden>
> > ---
> > CODING_STYLE | 12 +++++++-----
> > 1 files changed, 7 insertions(+), 5 deletions(-)
> >
> > diff --git a/CODING_STYLE b/CODING_STYLE
> > index a579cb1..c17c3f3 100644
> > --- a/CODING_STYLE
> > +++ b/CODING_STYLE
> > @@ -51,11 +51,13 @@ QEMU coding style.
> >
> > 4. Block structure
> >
> > -Every indented statement is braced; even if the block contains just one
> > -statement. The opening brace is on the line that contains the control
> > -flow statement that introduces the new block; the closing brace is on the
> > -same line as the else keyword, or on a line by itself if there is no else
> > -keyword. Example:
> > +Every control flow statement is followed by a new indented and braced
> > +block, except if it is followed by another control flow statement (else
> > +if) or by a condition (do {} while ()); even if the block contains just
> > +one statement. The opening brace is on the line that contains the
> > +control flow statement that introduces the new block; the closing
> > +brace is on the same line as the else keyword, or on a line by itself
> > +if there is no else keyword. Example:
>
> Nice try, but does it prevent this:
> if (x) for (;;) do {
> } while (0);
> ?
We should find a way to define "for (;;)" as a single statement.
> Maybe also "break" and "goto" can be considered control flow statements.
Correct, they should be excluded from there as they don't need to be
followed by braces.
> How about something like "wherever C syntax allows potentially
> ambiguous sequence of statements, braces must be used, with the
> exception of 'else' followed by 'if'"? Now the problem becomes
> defining ambiguous sequences of statements.
That's the problem. We have seen that people already take advantage of
the ambiguities, as I would have never have imagined someone writing the
code in the rationale of this patch to avoid putting braces.
--
Aurelien Jarno GPG: 1024D/F1BCDB73
address@hidden http://www.aurel32.net