home *** CD-ROM | disk | FTP | other *** search
/ DP Tool Club 8 / CDASC08.ISO / VRAC / MS_ARCAD.ZIP / ARC5_2.CHP < prev    next >
Text File  |  1993-06-15  |  5KB  |  134 lines
  1. %
  2. #EF
  3. #T15,1,Chapter 5     General Design Considerations     Pg. 6
  4. #HS,1,4,80,25,11,1
  5. #C4,R5
  6.                      ~W~IThe Fundamentals Of Structured Design~Y~I
  7.  
  8. Structured design is very easy. It's based on just a few simple ideas. The
  9. first is that a ~R~Istructured program~Y~I is a ~C~Iproper program ~Y~Icomposed of ~C~Iproper
  10. program segments~Y~I. ~C~IProper program segments ~Y~Iare built with a combination of
  11. ~M~Iselection~Y~I, ~M~Iiteration~Y~I, ~M~Isequence~Y~I, and ~M~Irecursion~Y~I. They use as much information
  12. and |implementation hiding| as possible. A proper program segment has the
  13. following characteristics:
  14.  
  15.     1.      Every module has a single entry and a single exit.
  16.     2.      There is no "dead code".
  17.     3.      There are no endless loops.
  18.  
  19. #WN
  20. %
  21. #EF
  22. #T15,1,Chapter 5     General Design Considerations     Pg. 7
  23. #HS,1,4,80,25,11,1
  24. #C4,R5
  25.                          ~W~ISingle Entry, Single Exit~Y~I
  26.  
  27. Single entry, single exit means just that; there is only one way to get in
  28. or out of a program segment. This necessarily implies that there are no
  29. GOTO's or other funky jumps to or from who-knows-where. Have you ever seen
  30. a jump from the Twilight Zone into the middle of an if-then-else statement?
  31. I have. Believe me it's no fun to maintain. Especially when there are
  32. several of them chained together.
  33.  
  34. #WN
  35. Multiple entries into a section of code and multiple exits out of it
  36. increase the number of paths through the code section |exponentially|. In
  37. other words, adding a few jumps into or out of a section of code makes it
  38. much harder to test fully. Code that is not fully tested is by definition
  39. more likely to have bugs.
  40.  
  41. #WN
  42. #C4,R20
  43. In addition, the |dependencies| between sections of code grows when we do
  44. unstructured jumps. This decreases the generality of the code, and
  45. therefore decreases our ability to plug the code into another program. That
  46. means we're probably not going to be very successful at being lazy.
  47.  
  48. #WP
  49. %
  50. #EF
  51. #T15,1,Chapter 5     General Design Considerations     Pg. 8
  52. #HS,1,4,80,25,11,1
  53. #C4,R5
  54.                               ~W~IDead Code~Y~I
  55.  
  56. ~M~IDead code~Y~I is code that can't ever be executed. It usually appears after
  57. there's been a modification. Something gets changed or taken out, and a
  58. statement is now in a location where it's no longer executed. Figure 5.2
  59. shows an example of dead code.
  60.  
  61.                              ~W~IFigure 5.2~Y~I
  62.                              Dead Code
  63.                         .
  64.                         .
  65.                         .
  66.         /* Lots of code preceding the dead code */
  67.         goto somewhere_else;
  68.         ~R~Ii++;                                    ~Y~I/* This is all dead code. */~R~I
  69.         trezzenvop=sqrt(gribble);               ~Y~I/* It can't be executed */~R~I
  70.         printf("Zerbleflatz\n");                ~Y~I/* unless the goto is */~R~I
  71.         snert=getchar();                       ~Y~I /* deleted. */
  72.  
  73. #WN
  74. #BO,44,8,78,22,7,1,0,13,15,6
  75. This is a time bomb waiting to
  76. explode. After a while, no one
  77. knows what these statements are
  78. for so they're afraid to take
  79. them out. One day when you're
  80. least expecting it, the code
  81. will change again and those
  82. statements will once more be
  83. executed. And like Dracula
  84. raised from the dead, they
  85. will invariably bite you in a
  86. big way and suck up all your
  87. time.
  88.  
  89. #WP
  90. %
  91. #EF
  92. #T15,1,Chapter 5     General Design Considerations     Pg. 9
  93. #HS,1,4,80,25,11,1
  94. #C4,R5
  95.                              ~W~IEndless Loops~Y~I
  96.  
  97. Endless loops are unfortunately all too common in C programs. To be totally
  98. honest, I use them once in a great while myself. But be warned, if they're
  99. not used sparingly they'll completely undermine the reliability of your
  100. program. Figure 5.3 shows an endless loop.
  101.  
  102.  
  103.                             ~W~IFigure 5.3~Y~I
  104.                          An endless loop
  105.  
  106.     /* This is endless because there is no specified termination
  107.     condition. */
  108.     for ~W~I(;;)~Y~I
  109.     {
  110.         do_a_function(a_parameter, another_parameter);
  111.         a_parameter *= another_parameter - strlen(something_profound);
  112.     }
  113.  
  114. #WP
  115. %
  116. #EF
  117. #T15,1,Chapter 5     General Design Considerations     Pg. 10
  118. #HS,1,4,80,25,11,1
  119. #C4,R5
  120. ~Y~IIn my work on a certain software project, I found that one of the Software
  121. Engineers on the program before me used endless loops quite liberally. The
  122. result was that, in many cases, the software would lock up after I made a
  123. slight modification. It was infuriating to have to try and track down the
  124. endless loop responsible. This usually wasn't easy because the computer I
  125. was working on was a |parallel processing system|, and the loops often
  126. involved interaction between the processors.
  127.  
  128. #WN
  129. #C4,R13
  130. The only time I use endless loops is in applications that ~S~M~Inever terminate~Y~I,~s
  131. like operating systems. Even then, I only put them in at the ~W~Ihighest level~Y~I
  132. possible. Moderation is the best policy when it comes to endless loops.
  133. #WP
  134. #X