home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / lang / cplus / 13053 < prev    next >
Encoding:
Internet Message Format  |  1992-08-29  |  2.5 KB
  1. Path: sparky!uunet!sun-barr!ames!pacbell.com!UB.com!igor!thor!rmartin
  2. From: rmartin@thor.Rational.COM (Bob Martin)
  3. Newsgroups: comp.lang.c++
  4. Subject: Re: GOTO, was: Tiny proposal for na
  5. Message-ID: <rmartin.715102882@thor>
  6. Date: 29 Aug 92 15:41:22 GMT
  7. References: <714668024@thor> <6800007@tisdec.tis.tandy.com> <1992Aug26.130335.26725@hemlock.cray.com> <1992Aug26.194538.1598@spss.com> <rmartin.714931485@thor> <1992Aug27.181013.29933@spss.com>
  8. Sender: news@Rational.COM
  9. Lines: 47
  10.  
  11. hosken@spss.com (Bill Hosken) writes:
  12.  
  13. >The rule "avoid goto" does not stop anyone from writing confusing
  14. >code.  It probably makes some people think more about the code
  15. >they write when seeking alternatives to the goto, but taken alone
  16. >it does little good.  
  17.  
  18. I don't agree.  Taken alone, it forces your code to have a "known"
  19. structure.  This doesn't mean that the code is "good code", it just
  20. means that there are some basic rules that the reader/maintainer can
  21. depend upon.  This have significant value.
  22.  
  23. >A better rule would be "Be prepared to give a clear and convincing
  24. >argument that the code is correct". 
  25.  
  26. But what is "correct code"?  Code that works?  I can write code that
  27. works, but is unmaintainable.  If all we want to produce is "code that
  28. works", then the nightmares which have plagued us from the late
  29. sixties on are sure to continue.
  30.  
  31. What we want is:
  32.  
  33.     Code that works.
  34.     Code that is maintainable.
  35.     Code that is reusable.
  36.     
  37. Each of these three aspects requires thought and effort on the part
  38. of the designer.  Moreover, the easiest of the three tasks, is the
  39. first.  Any high school comp-sci geek can cajole a bunch of program
  40. statements into working.  But to write code which others can
  41. understand and eaily alter, or which others can re-use in a different
  42. context takes thought, planning and work.
  43.  
  44. Now, there are some rules which we have learned over the years which
  45. help this process.  One of them is "don't use gotos", another is "use
  46. single-entry, single-exit constructs".  If we follow these rules, then
  47. we can concentrate on the job at hand, i.e. the correctness,
  48. maintainability and reusability of our code.  But if we ignore those
  49. rules, then we add more variables to the problem we are trying to
  50. solve.  And if we break the rules, and provide justifications, then we
  51. have expended effort in the wrong direction.
  52.  
  53. --
  54. Robert Martin                        Training courses offered in:
  55. R. C. M. Consulting                       Object Oriented Analysis
  56. 2080 Cranbrook Rd.                        Object Oriented Design
  57. Green Oaks, Il 60048 (708) 918-1004       C++
  58.