Path: utzoo!utgpu!watserv1!watmath!att!dptg!ulysses!andante!princeton!udel!rochester!pt.cs.cmu.edu!o.gp.cs.cmu.edu!andrew.cmu.edu!ghoti+
From: ghoti+@andrew.cmu.edu (Adam Stoller)
Newsgroups: comp.lang.c
Subject: Re: Coding Standards. was: a style question
Message-ID: <kbFz5rq00asV8C1qRk@andrew.cmu.edu>
Date: 19 Nov 90 14:51:35 GMT
References: <1990Oct23.160116.10299@athena.mit.edu> <13@christmas.UUCP> <14369@smoke.brl.mil> <1990Nov10.191840.21113@clear.com> <IMP.90Nov16123956@marvin.Solbourne.COM>
Organization: Information Technology Center, Carnegie Mellon, Pittsburgh, PA
Lines: 78
In-Reply-To: <IMP.90Nov16123956@marvin.Solbourne.COM>

Excerpts from netnews.comp.lang.c: 16-Nov-90 Re: Coding Standards.
was:.. Warner Losh@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