one return per function (was: Wanted: advice on a good C textbook)

[Doug Gwyn]

In article <45458 at oliveb.olivetti.com> comp.lang.c writes:
>Caveat:  There is one sentence in the book (the first edition, I think)
>where Holub advocates the "one return per function" idea a la Pascal.

There are valid reasons for such a recommendation.  The strongest one I
know of has reliability as its goal:  Standard program verification
techniques require partitioning of the source code into sequential
chunks, with assertions to be verified at the partitions.  Unconstrained
use of goto, continue, break, return, and the like greatly add to the
complexity of proving program correctness, which is already hard enough.

Having explained that, I admit that I normally use much less rigid
criteria and usually feel free to simply return(ERROR) when things go
wrong in the middle of a function.  However, when I'm building systems
where reliability is a foremost goal, I'm much more careful to route
all return paths through limited sections of code, where assertions can
be more conveniently verified.