gwyn@smoke.BRL.MIL (Doug Gwyn) (07/26/89)
In article <45458@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.