home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / lang / cplus / 13255 < prev    next >
Encoding:
Internet Message Format  |  1992-09-03  |  2.4 KB
  1. Path: sparky!uunet!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.715526582@thor>
  6. Date: 3 Sep 92 13:23:02 GMT
  7. References: <2318@devnull.mpd.tandem.com> <rmartin.715001372@thor> <4192@papaya.bbn.com> <1992Sep2.131733.20676@terminator.cc.umich.edu>
  8. Sender: news@Rational.COM
  9. Lines: 44
  10.  
  11. potts@itl.itd.umich.edu (Paul Potts) writes:
  12.  
  13. |I use "goto" sparingly as well, and agree that it can be very useful in
  14. |cases, and even make code *more* readable. BASICally <grin> I use it 
  15. |only to exit from loops where adding additional conditions to the loop
  16. |would make the code much more obscure and slow, or to skip down past a
  17. |piece of code to the end of the loop under some circumstances. 
  18.  
  19. |To make GOTO more readable, NEVER go backwards in your code, only
  20. |forwards; use only one GOTO in a block, and comment explicitly. If GOTO
  21. |is used only under certain conditions, the argument against writing
  22. |spaghetti code really doesn't apply.
  23.  
  24. Paul, though you rail against the proscription of goto, you have
  25. simply replaced it with several proscriptions and warnings of your own
  26. making.  You tell us NEVER to do some things, and to "skip down" in
  27. "some circumstances" and "use only one" in others.  
  28.  
  29. I am sure that there are others who might disagree with your "one goto
  30. per block" rule.  Others may disagree with your "NEVER go backwards"
  31. rule.
  32.  
  33. You don't have to make up your own rules.  Some other guys, who have
  34. thought about it alot, have put together a pretty well thought through
  35. set of rules.  Moreover, the industry has, for the most part, accepted
  36. those rules as valid.  Moreover, it has been proven that those rules
  37. are always workable, and it has been shown that they help to make code
  38. more readable and maintainable.  
  39.  
  40. So, why invent your own?  
  41.  
  42. Now, granted, there are some cases where the rules of Structure
  43. Programming do not create the most efficient possible code.  And in
  44. cases where efficiency is of primary importance, then the rules should
  45. be violated, without regret.
  46.  
  47. But in most cases, there is no good reason to invent your own, ad-hoc,
  48. software methodology.
  49.  
  50. --
  51. Robert Martin                        Training courses offered in:
  52. R. C. M. Consulting                       Object Oriented Analysis
  53. 2080 Cranbrook Rd.                        Object Oriented Design
  54. Green Oaks, Il 60048 (708) 918-1004       C++
  55.