Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!husc6!encore!zelig!jdarcy From: jdarcy@encore.com (Jeff d'Arcy) Newsgroups: comp.lang.c Subject: Re: Coding Standards. was: a style question Message-ID: Date: 18 Nov 90 18:03:18 GMT References: <1990Nov18.034120.2963@bushido.uucp> Sender: news@Encore.COM Lines: 42 dbc@bushido.uucp (Dave Caswell) writes: >rules like having a single entrance and exit point are good >ones. They should be written down and strictly enforced. Blech! Consider the following example: int fubar (x, y, z) int x, y, z; { if (abnormal_condition_1) return(foo); if (abnormal_condition_2) return(bar); for (blah; blah; blah) { do_some_stuff(); if (screwed_up) return(foobar); do_other_stuff(); } return(blech); } If you enforce a single-exit-point rule the code will be obfuscated to a pretty high degree. For starters you'd have to declare a dummy return variable to hold values for the abnormal_condition cases, just so you can use it at your single exit point. Then you'd have the entire for loop encased in an unnecessary extra if statement, contributing to "indentation creep", that nasty syndrome where the real work in a routine is indented halfway across the page. To get rid of the return statement in the for loop you'd either have to use a break (another no-no) or add a new status variable, making the loop condition more complex and indenting the bottom part of the for loop still further. In short, the handstands you'd have to do to enforce a single-exit-point rule make the code *less* readable and often less efficient as well even in simple cases such as this. I'm rabidly opposed to unconstrained goto statements, but return, break and continue are controlled enough to be worthwhile. -- Jeff d'Arcy, Generic Software Engineer - jdarcy@encore.com Ask me if I care. . .maybe I do