Coding Standards. was: a style question

[Adam Stoller]

Excerpts from netnews.comp.lang.c: 16-Nov-90 Re: Coding Standards.
was:.. Warner Losh at marvin.Solbo (1834)

> When what I really want is:

> 	if (!allocate-memory)
> 		return NO_MEM

> 	do some stuff

> 	if (!get-more-memory)
> 		return NO_MEM

> 	do more stuff

> 	if (!openfile)
> 		return NO_FILE

> 	do even more stuff

> 	if (!alloc memory)
> 		return NO_MEM

> 	last stuff
> 	
> 	return OK;


The final one is the clearest one, IHO, of them all.  Comments.

Well, if you're looking for a highly maintainable coding standard - you
would be better off keeping the braces for each if/else/for/while/(etc)
loops (not to mention the semicolons after the return statements;-) -
i.e.:

{
    if (!allocate-memory){
        return (NO_MEM);
    }
    /* do some stuff */

    if (!get-more-memory){
        return (NO_MEM);
    }
    /* do more stuff */

    if (!openfile){
        return (NO_FILE);
    }
    /* do even more stuff */

    if (!alloc memory){
        return (NO_MEM);
    }
    /* last stuff */
    return (OK);
}

Whether or not to put parens around the argument to return is, of
course, another tidbit of religious wardom, I prefer to do it, a lot of
other people prefer not to - whatever you do, you should try to be
consistant.

As for the braces - the reason for them is that it helps to avoid nasty
situations when the next person maintaining the code has to add one more
thing before the return statement - and doesn't realize that there
wasn't a set of braces around it to begin with.  By always putting the
braces there, you waste a fairly insignificant amount of space, do
nothing if not improve readabiltiy, and increase the maintainability (by
others) quite a bit -- by not leaving the door open for those simple to
make (and often hard to find) bugs.

Other than that, I agree with you in that I find your third example
(with above modification) much clearer to work with than the [in]finite
nesting, or goto style.

--fish