gefrank@sdrc.UUCP (Frank Glandorf) (10/04/90)
Answer: Same reasons as FORTRAN, Pascal, PL/1, etc. While checking out some code the other day I came across a rather obscure looking function and decided to restructure it to try to understand it. The function determines if a set of surfaces forms a closed object. The number of lines was reduced from about 250 to 110. The number of local variables was reduced from 49 to 33 (three of which are const). The number of control flow structures was reduced from 31 to 13. The first task was a superficial cleanup. This consists of a uniform indentation style, elimination of curly braces from single line control structures, replacing of lines of comment stars with blank lines, replacing literal "magic values" with symbolic names, and replacing multiple line statements with single lines. The next method applied was to make use of procedural abstraction. This eliminated eight for loops (note: there are about four lines per loop). The following types of functions were used: vector sum, vector difference, vector times a scalar, vector copy, and cosine of angle between two vectors. The largest simplifications result from a true understanding of the function. In one case two nearly identical sequential while loops were combined. The first loop is used to find a nondangling surface and save some information about it. The second loop finds a nondangling surface which is closer to some point than the previous surface and saves the same information about it. The two loops can be combined by adding a variable which tracks if a previous surface has been saved. In another case the cosine of the angle between two vectors is computed and a set of nested if-then-else statements are used to set the open/closed object flag. The nine lines of inline cosine computation were replaced with a function call. Every other line of this section had a comment describing the vector operations. None of them stated the intent of this section which was to determine if the angle between two vectors was acute. Three errors were uncovered by restructuring the code. The first was a variable which had not been set correctly. Another error resulted from returning an error code from a system which had no meaning for this function. The last error failed to free allocated memory when finished with it. To be fair, I doubt if this module had started out this complex. There are half a dozen modifications listed. A large function seems to grow more than a small one since during its maintenance one is more likely to patch a large function and restructure a small one. -Frank
timr@gssc.UUCP (Tim Roberts) (10/04/90)
Listen, if it was supposed to be easy to understand, we wouldn't call it "code". :-) -- timr@gssc.gss.com Tim N Roberts, CCP Graphic Software Systems I think Lotus should come out with a PS/1 spreadsheet. They could call it 0-1-2.
ems@aristotle.JPL.NASA.gov (Eric Slimko) (10/05/90)
Code isn't hard to understand. Programmers are hard to understand. ----------- -- Eric Slimko | Jet Propulsion Laboratories ems@socrates.jpl.nasa.gov | NASA/CalTech