ACM Home Page
Please provide us with feedback. Feedback
Improving computer program readability to aid modification
Full text PdfPdf (989 KB)
Source
Communications of the ACM archive
Volume 25 ,  Issue 8  (August 1982) table of contents
Pages: 512 - 521  
Year of Publication: 1982
ISSN:0001-0782
Authors
James L. Elshoff  General Motors Research Lab., Warren, MI
Michael Marcotty  General Motors Research Lab., Warren, MI
Publisher
ACM  New York, NY, USA
Bibliometrics
Downloads (6 Weeks): 12,   Downloads (12 Months): 73,   Citation Count: 10
Additional Information:

references   cited by   index terms   collaborative colleagues  

Tools and Actions: Request Permissions Request Permissions    Review this Article  
DOI Bookmark: Use this link to bookmark this Article: http://doi.acm.org/10.1145/358589.358596
What is a DOI?

REFERENCES

Note: OCR errors may be found in this Reference List extracted from the full text article. ACM has opted to expose the complete List rather than only correct and linked references.

 
1
Ashcrofi, E., and Manna, Z. The translation of'GOTO' programs to 'WHILE' programs. Proc. 1971 IF1P Congress, Ljubljana, Yugoslavia, Aug. 1971, pp. 250-255. Demonstrates that every flowchart program can be written without GO TO statements by using WHILE statements.
 
2
Boehm, B. Software engineering. IEEE Trans. Comptrs. C-25, 12 (Dec. 1976), 1226-1241. Provides a definition of the term "software engineering" and a survey of the state of the art of software production in 1976. Contains an extensive set of references.
3
 
4
Elshoff, J.L. A case study of experiences with top down design and structured programming. GMR-1742, Comptr. Sci. Dept., General Motors Res. Labs., Warren, Mich., Oct. 1974. Describes the author's personal experiences in consciously using top down development techniques and structured programming techniques.
 
5
Elshofl, J.L. Defensive programming. GMR-1799, Comptr. Sci. Dept., General Motors Res. Labs., Warren, Mich., Feb. 1975. Presents a description of the techniques of defensive programming and some of the trade-offs that should be considered by programmers using them.
 
6
Elshoff, J.L. An analysis of some commerical PL/I programs. IEEE Trans. Software Eng. SE-2, 2 (June 1976), 113-120. Presents the results of studying 120 commercial PL/I programs with respect to their size, readability, complexity, programming discipline, and use of programming language.
 
7
Elshoff, J.L. The influence of structured programming on PL/I program profiles. IEEE Trans. Software Eng. SE-3, 5 (Sept. 1977), 364-368. Studies two sets of commercial PL/I programs representing programming practice before and after the introduction of structured programming techniques.
8
 
9
Gordon, R.D. Measuring improvements in program clarity. IEEE Trans. Software Eng. SE-5, 2 (March 1979), 79-90. A functional relation between the clarity of a program and the number and frequency of operators and operands in the program is presented. This measure of program clarity gives an estimate of the amount of mental effort required to understand the program.
 
10
 
11
 
12
IBM. OS PL/I Checkout,Compiler: Programmer's Guide. Pub. SC33-0007, IBM Corp., White Plains, New York, Oct. 1976, 4th edition.
 
13
 
14
Lehman, M.M. Laws and conservation in large-program evolution. Proc. 2nd Software Life Cycle Management Workshop, Atlanta, Georgia, 1978 (IEEE Pub. 78CH 1390-4C, pp. 140-145). Lehman describes natural phenomena observed about the way in which the maintenance and evolution of large programs are planned, managed, and implemented.
 
15
 
16
Liu, C.C. A look at software maintenance. Datamation 22, 11 (Nov. 1976), 51-55. Investigates the problems of software maintenance and describes some improvements, in particular, in the areas of documentation and testing.
 
17
McCabe, T.J. A complexity measure. IEEE Trans. Software Eng. SE-2, 4 (Dec. 1976), 308-320. McCabe describes a graph-theoretic program complexity measure that depends only on the decision structure of the program. The use of this measure to manage and control program complexity is described.
 
18
Mills, H.D. Mathematical foundations for structured programming. Doc. FSC72-6012, IBM Federal Syst. Div., Gaithersburg, Md., Feb. 1972. The programming process is formulated as a step-by-step expansion of mathematical functions. A structure theorem guaranteeing that any program that can be represented as a flowgraph can be transformed into one containing only three types of structures--sequence, conditional, and iterativeis proved.
 
19
20
 
21
Sheppard, S.B., et al. Modern coding practices and programmer performance. IEEE Computer 12, (Dec. 1979), 4149. Describes the results of a series of experiments on the effects of modern coding practices on programming comprehension, program modification, and debugging performance.
 
22
Standish, T.A., et al. The lrvine Program Tran.formation Catalogue. Dept. Inform. and Comptr. Sci., Univ. of Calif at Irvine, Irvine, Calif., 1976. A source book of ideas for improving programs through source-to-source transformations.
 
23
Stevens, W.P. Using Structured Design. Wiley-Interscience, New York, 1981. Illustrates the techniques of structured design with numerous examples that demonstrate guidelines for splitting a program into separate modules,
 
24

CITED BY  10

Collaborative Colleagues:
James L. Elshoff: colleagues
Michael Marcotty: colleagues