music

OSdata.com

modular programming

summary

    This subchapter looks at modular programming.

free computer programming text book project table of contents If you like the idea of this project, then please donate some money. more information on donating

stub section

    This subchapter is a stub section. It will be filled in with instructional material later. For now it serves the purpose of a place holder for the order of instruction.

    Professors are invited to give feedback on both the proposed contents and the propsed order of this text book. Send commentary to Milo, PO Box 1361, Tustin, California, 92781, USA.

modular programming

    This subchapter looks at modular programming.

other

   “Common sense also leads us to the recognition of the characteristics of programs that makes the programs maintainable. Above all, we look for programs that exhibit logical simplicity — failing that, at least clarity. The earmarks of simplicity and clarity include modularity (true functional modularity, not arbitrary segmentation) and a hierarchical control structure, restrictions on each module’s access to data, structured data forms, the use of structured control forms, and generous and accurate annotation.
   “Much has been said of the technical members of this set in earlier pages. Of good annotation, there are several features that must be included. First, the header information of each procedure should provide a concise statement of the procedure’s external specifications, including a description of input and output data. Each section of the procedure should be introduced by comments identifying the section’s relation to the external characteristics. Finally, comments within each section should relate groups of statements to the program’s documented description. This last is automatically achieved by using design language statements as source code comments.” —Robert Dunn. Software Defect Removal. McGraw-Hill, 1984, pg. 308

   “15. Everything should be built top-down, except the first time.” —Alan Perlis, Epigrams on Programming, ACM’s SIGPLAN Notices Volume 17, No. 9, September 1982, pages 7-13

   “31. Simplicity does not precede complexity, but follows it.” —Alan Perlis, Epigrams on Programming, ACM’s SIGPLAN Notices Volume 17, No. 9, September 1982, pages 7-13

   “38. Structured Programming supports the law of the excluded muddle.” —Alan Perlis, Epigrams on Programming, ACM’s SIGPLAN Notices Volume 17, No. 9, September 1982, pages 7-13

   “57. It is easier to change the specification to fit the program than vice versa.” —Alan Perlis, Epigrams on Programming, ACM’s SIGPLAN Notices Volume 17, No. 9, September 1982, pages 7-13

   “58. Fools ignore complexity. Pragmatists suffer it. Some can avoid it. Geniuses remove it.” —Alan Perlis, Epigrams on Programming, ACM’s SIGPLAN Notices Volume 17, No. 9, September 1982, pages 7-13

chapter contents

• simple procedures
• code blocks
• scope
• step-wise refinement
• no operation/null statement

---