Path: utzoo!mnetor!uunet!husc6!cca!g-rh From: g-rh@cca.CCA.COM (Richard Harter) Newsgroups: comp.lang.c Subject: Structured design, goto's, and the holy grail Message-ID: <23777@cca.CCA.COM> Date: 29 Jan 88 06:05:35 GMT References: <11528@brl-adm.ARPA> Reply-To: g-rh@CCA.CCA.COM.UUCP (Richard Harter) Organization: Computer Corp. of America, Cambridge, MA Lines: 81 Summary: Was something else, changed the title to match the content In article <11528@brl-adm.ARPA> dsill@NSWC-OAS.arpa (Dave Sill) writes: >In article <22580001@uxe.cso.uiuc.edu> mcdonald@uxe.cso.uiuc.EDU writes: >>[Doug Gwyn, I believe, writes:] >>>Actually, inter-module communication via global data is contrary to >>>well-established structured design principles. It should be used >>>sparingly or not at all. >> >>Bullshit. Inter-module communication via global data is probably the most >>potent method (to the programmer, not internal to a compiler) available >>for both space and time optimization. Particularly space. Interesting issue. There is a school that holds that inter-module communication via global data is undesirable (strong, unstructured coupling.) This school is wrong. If procedure invocation is strictly heirarchical, and all communication is via parameter sequences, then there are large classes of programs which effectively cannot be written. If procedure invocation is non-heirarchical (i.e. you can call a routine from anywhere) and you can have variables remembered from one invocation to the next, then a simulation of global data is trivial. Heirarchical structure and data localization lead to clean comprehensible software, when they are applicable. Some have concluded that all software should be written this way. The position is an error; there are (demonstratably) large classes of programs where this type of structure is not effective. The problem with global data, the goto, the procedure that can be called from anywhere, et al, is that these are primitive constructs that do not have structure associated with them. The fundamental problem is lay out principles of structuring that can be used in general, and not merely in a restricted subclass of problems. >Yeah, structured design has a habit of outlawing some of the most >powerful techiques, e.g. the "goto". This particular statement is false in its implications, although technically true. There is a definite heirarchy of strength of control structure constructs, running as follows: (1) if-then-else and while loops (2) forever loops with conditional escapes (3) conditional goto's (4) subroutine call/return (5) computed goto's (case statement) Stength here means that there are programs which can be written using a higher level construct which cannot be written using only lower level constructs with paying either exponential penalties in space or logarithm penalties in time. Forgoing the goto means, at most, loss of micro efficiencies as long as one retains (4) and (5), which most structured programming advocates do. The implication of the quoted sentence is that "power" is unstructured and therefore "bad". It is not the power of the goto that is "bad" -- there are more powerful constructs -- it is its obscurity. It should be noted that procedure invocation has the same problem as the goto -- you cannot tell, from the code within the procedure how you got there. Modularization is often cited as an important programming principle, and it is. But what it really does is push the problem up the scale. When you have hundreds or thousands of modules, you have the same kinds of problems as when you have hundreds or thousands of statement numbers. >For some odd reason, the >proponents of structured design seem to feel that it's important to >make code easy to understand, modify, and maintain. And have you stopped beating your wife? One might well agree that it is desirable to make code easy to understand, modify, and maintain, and yet believe that the proponents of structured design offer a pseudo solution that makes the objective harder to attain because their 'solution' is based on a fundamental misunderstanding of the problem. Or, to put it bluntly, replacing reason by religion may get you to Heaven, but it is not the way to produce good software. [Note: I do not necessarily endorse this view nor oppose it.] -- In the fields of Hell where the grass grows high Are the graves of dreams allowed to die. Richard Harter, SMDS Inc.