Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!uunet!kim From: kim@kim.misemi (Kim Letkeman) Newsgroups: comp.lang.c Subject: Re: The final word on GOTO (Don't I wis Message-ID: <1044@kim.misemi> Date: 29 Sep 89 16:54:47 GMT References: <20324@<1989Sep14> <225800222@uxe.cso.uiuc.edu> <4208@cbnewsh.ATT.COM> <1017@kim.misemi> <598@crdos1.crd.ge.COM> Organization: MITEL Corporation, Kanata, Ontario, Canada. Lines: 67 In-reply-to: davidsen@crdos1.crd.ge.COM's message of 28 Sep 89 15:15:59 GMT In article <598@crdos1.crd.ge.COM> davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) writes: > In article <1017@kim.misemi>, kim@kim.misemi (Kim Letkeman) writes: > | If you keep your programs well structured, with *small* functions that > | fan out smoothly from control level functions to low level (working) > | functions, then this situation just doesn't arise. > Size and structure are not exclusive. A switch within two for loops > seems like a reasonable structure to me, but it can contain a lot of > cases. If the code for each case is small, say 1-2 statements each, > using a table lookup and procedure per case can add a lot of overhead, > and encourages pollution of global namespace to make variables > available. This is a fairly rare occurence in my experience. In a situation where you have a couple of nested loops where the lowest level contains many cases with only one or two lines each, a clean way in which to express this is to separate the function being performed at the lowest level into a separate procedure. (You can pass that procedure the data it needs.) This leaves the higher level "control" procedure at a reasonable size with its structure quite obvious. Essentially, this part of the goto thread is about (IMO) software structure as it pertains to readablility and maintainability. The optimization part of this thread is a separate issue. So, if we consider readability and maintainability as desirable attributes (likely a general consensus), then anything that contributes to that is also desirable. Small procedures contribute. > All big procedures are not badly structured, and efforts to keep the > lines per procedure down to some arbitrary limit cost time to write, to > run, and to maintain. True. A big procedure is not necessarily badly structured. But that does not make it easy to read. In fact, a procedure that grows beyond your immediate field of view (24 lines on terminals, more on listings and workstations) is *automatically* harder to read since you have less context within your immediate grasp. Some procedures *must* grow larger than your normal field of view. Granted. But this does not excuse someone who habitually codes 100 line functions or procedures. The circumstances in which a single control procedure needs to be longer than say, 50 lines (which I consider too large as it is) are quite rare. If you examine almost any procedure of this size, you will see that it performs functions at two levels of control. Or even worse, two functions at the same level of control. Or really horrible, two completely independent functions at the same level of control where a switch passed in determines the action performed. As a general principle, writing a single procedure to perform a single function (task) is the whole point behind so called structured programming. Coupling and cohesion and all that. So where does the goto fit after all this? It doesn't. > | I apologize if this message has a pious tone. > It certainly could be read that way... True. But then so could anything written by someone with strongly held beliefs. Especially if you disagree with that person's most basic premises. -- Kim Letkeman uunet!mitel!spock!kim