Re: cooking the spaghetti

luser-ex-troll <mijoryx@xxxxxxxxx> writes:
On Mar 25, 2:15 pm, Keith Thompson <ks...@xxxxxxx> wrote:
luser-ex-troll <mijo...@xxxxxxxxx> writes:
[...]
#define NBUF 10
int main() { char buf[NBUF] = "";
    while (-1 != toke(buf,NBUF)) /**/;
return 0; }

/*eof*/

I find your code layout to be jarring.  I'd write the above as:

    int main(void)
    {
        char buf[NBUF] = "";
        while (-1 != toke(buf, NBUF)) {
            continue;
        }
        return 0;
    }

(Actually there are some other changes I'd make, but I limited myself
to adding the void keyword and changing the layout.)

Seriously? 8 lines versus 3? Perhaps my hardware constraints have
suggested more terseness (The olpc xo-1 has a 6"x4.5" lcd), but here I
think it really pays off. It is, after all, a stub for testing the
module before linking into the larger program.

But I'm truly curious to know how you would really format it: blank
lines after declarations and before return?

There are several minor style points here on which I'm undecided. I
might put the opening brace for the function either on the same line
as the prototype or on the next line by itself; the former is more
consistent with they way I use braces in other contexts, and the
latter is probably a throwback to K&R C, where parameter declarations
are typically separated from the function declaration.

How to write a loop with an emtpy body is another thing on which I'm
undecided. I always use braces for compound statements, even when
they're not necessary (a habit I picked up from Perl where they're
always mandatory, but I find it safer and more consistent in C as
well). I used the "continue" keyword here because I think it clearly
expresses what's going on; I might use an empty comment instead if I
were in the mood. I wouldn't use
while (condition);
because it's just too terse for my tastes, and too easy to mistake for
a typo. Your own empty comment on the same line isn't bad.

I might put a blank line between the declarations and statements, but
I might not bother for something this small.

I think I see why you put the return statement on a different
indentation than the rest of the function body, but I wouldn't do it
that way; syntactically, return is just another statement. And I
really dislike putting code on a line after a '{', or before a '}'.

Here's another way I might write it if I were a bit more concerned
with vertical space.

int main(void) {
char buf[NBUF] = "";
while (toke(buf, NBUF) != -1) continue;
return 0;
}

In real life, I'd follow my employer's coding standards if I were
writing code for work, or the style of the existing code if I were
working on an existing project. But if I were writing my own code for
my own purposes, I'd feel free to indulge my own idiosyncracies (which
are of course far more rational and consistent than everyone else's
idiosyncracies).

--
Keith Thompson (The_Other_Keith) kst-u@xxxxxxx <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
.

Relevant Pages

  • Re: how to make large macro paste the code as it is
    ... unsigned int a1;\ ... too many variable declarations in same line. ...     foo; ...
    (comp.lang.c)
  • Re: Why is this not an error in Visual C?
    ... says that when an old-style function definition is processed, ... That is, I think, `int fint x; ... Concerning the compatibility of function ... All declarations in the same scope that refer to the same object or function ...
    (comp.lang.c)
  • Re: Why is this not an error in Visual C?
    ... int foo ... What we're looking for to describe MSVC as broken is a constraint ... involve declarations of incompatible types. ... compatibility and of a composite type, ...
    (comp.lang.c)
  • Re: Why is this not an error in Visual C?
    ... says that when an old-style function definition is processed, ... That is, I think, `int fint x; ... Concerning the compatibility of function ... All declarations in the same scope that refer to the same object or function ...
    (comp.lang.c)
  • stylish albeit terse?
    ... to adding the void keyword and changing the layout.) ... latter is probably a throwback to K&R C, where parameter declarations ... but I find it safer and more consistent in C as ...     while; ...
    (comp.lang.c)