home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / lang / cplus / 13164 < prev    next >
Encoding:
Text File  |  1992-09-01  |  4.4 KB  |  115 lines
  1. Path: sparky!uunet!zaphod.mps.ohio-state.edu!rpi!bu.edu!news.bbn.com!papaya.bbn.com!cbarber
  2. From: cbarber@bbn.com (Chris Barber)
  3. Newsgroups: comp.lang.c++
  4. Subject: Re: GOTO, was: Tiny proposal for na
  5. Message-ID: <4192@papaya.bbn.com>
  6. Date: 1 Sep 92 21:43:17 GMT
  7. References: <714668024@thor> <6800007@tisdec.tis.tandy.com> <rmartin.714863091@thor> <2318@devnull.mpd.tandem.com> <rmartin.715001372@thor>
  8. Organization: BBN Systems and Technology, Inc.
  9. Lines: 104
  10.  
  11. In article <rmartin.715001372@thor> 
  12. >rgp@mpd.tandem.com (Ramon Pantin) writes:
  13. >|From my informal counts in this thread it seems that most people are
  14. >|perfectly happy with break, continue and mid-function returns.  Some
  15. >|group of people avoid gotos as a rule of thumb but wouldn't mind using
  16. >|them if required, some of these have not used a goto in the last 10 years.
  17. >|A smaller group (only you?) avoid all of these contructs completely.
  18.  
  19. rmartin@thor.Rational.COM (Bob Martin) writes:
  20. >I can assure you, it is not only me.  There has been a fair amount of
  21. >private mail on the subject.  However your observation is correct.  It
  22. >does seem that many programmers are quite happy using break and
  23. >continue.  Moreover, it seems that a smaller, but significant number
  24. >of programmers are content to use goto rather than structure their code.
  25.  
  26. Well I must admit that it seems that most people posting on this topic
  27. say that they do not use gotos, even those who disagree with you. So I
  28. guess I will just have to come out of the closet and admit that I have
  29. been using them for several years and with no regrets. I can't recall 
  30. finding any bugs that were related to my use of gotos and I haven't heard
  31. any complaints about the readability of my code. In fact, I resent your
  32. implication that because I use gotos I am lazy and write unstructured
  33. code. Although I use gotos frequently, I use them almost entirely for 
  34. clean up code used in error handling. For example:
  35.  
  36. My way:
  37.  
  38. void foo(void)
  39. {
  40.     FILE *fp = NULL ;
  41.     char *data = NULL ;
  42.  
  43.     if ((fp = fopen("foo", "r")) == NULL)
  44.         goto cleanup ;
  45.  
  46.     data = malloc(DATASIZE) ;
  47.  
  48.     if (DoStuff(fp, data) == ERROR)
  49.         goto cleanup ;
  50.  
  51.     DoMoreStuff(data) ;
  52.  
  53.  cleanup:
  54.     if (fp)
  55.         (void)fclose(fp) ;
  56.     if (data)
  57.         free(data) ;
  58. }
  59.  
  60. "Structured" version:
  61.  
  62. void foo(void)
  63. {
  64.     FILE *fp ;
  65.     char *data ;
  66.  
  67.     if (fp = fopen("foo", "r"))
  68.     {
  69.         data = malloc(DATASIZE) ;
  70.         if (DoStuff(fp, data) != ERROR)
  71.         {
  72.             DoMoreStuff(data) ;            
  73.         }
  74.         free(data) ;
  75.         (void)fclose(fp) ;
  76.     }
  77. }
  78.  
  79. The two examples are roughly equivalent in size (ignoring whitespace).
  80. My way is perfectly safe and maintainable as long as you ensure that
  81. all data that is refered to in the cleanup section is initialized before
  82. the first goto is encountered. The main difference between these is that
  83. the second case has two levels of nesting while mine has none, and that
  84. mine has to take a little extra time to check variable values when cleaning
  85. up. I must admit, that for a simple example like this, I would actually
  86. prefer the second case, but imagine what would happen if we added an 
  87. extra 5 or 6 steps to the function, each of which could cause the 
  88. function to abort. This would add an extra 5 or 6 levels of nesting
  89. in the second case would making the code much harder to read. The basic
  90. idea with my approach is to make the code readable in terms of what the
  91. code will do when functions do not fail, in other words, I want the code
  92. to look as much as possible like the case that does no error handling.
  93.  
  94. >Perhaps this is a contributing factor to the software crisis in this
  95. >country, and to why our bug rate per line of code is 100 to 1000 times
  96. >greater than it is in Japan.  I have not seen a study of such a
  97. >relationship, and I don't know how closely the Japanese adhere to the
  98. >principles of Structured Programming, but it is thought provoking, at
  99. >least to me.
  100.  
  101. This would be a strong argument if you would provide documentation
  102. about where you got the bug rate figure and could show that the 
  103. Japanese don't use gotos. Otherwise, I think this is irrelevant.
  104. Japense bug rates probably have much more to do with project management
  105. techniques and philosphy than any particular coding practice.
  106.  
  107. BTW, I *did* try writing code with no gotos, breaks, and continues
  108. several years ago but I didn't see that I was getting any particular
  109. benefit from it so I stopped.
  110.  
  111.  
  112. -- 
  113. Christopher Barber
  114. (cbarber@bbn.com)
  115.