Editing COBOL (section)

===Lack of structure===
In the 1970s, adoption of the [[structured programming]] paradigm was becoming increasingly widespread. [[Edsger Dijkstra]], a preeminent computer scientist, wrote a [[letter to the editor]] of [[Communications of the ACM]], published in 1975 entitled "How do we tell truths that might hurt?", in which he was critical of COBOL and several other contemporary languages; remarking that "the use of COBOL cripples the mind".<ref name="Dijkstra1">{{cite web |url=http://www.cs.utexas.edu/users/EWD/transcriptions/EWD04xx/EWD498.html |title=How do we tell truths that might hurt? |access-date=29 August 2007 |publisher=University of Texas at Austin |date=18 June 1975 |last=Dijkstra |first=Edsger W. |id=EWD498 |archive-url= https://web.archive.org/web/20170502143353/http://www.cs.utexas.edu/users/EWD/transcriptions/EWD04xx/EWD498.html |archive-date=2 May 2017 |url-status=dead}}</ref>

In a published dissent to Dijkstra's remarks, the computer scientist Howard E. Tompkins claimed that [[unstructured programming|unstructured]] COBOL tended to be "written by programmers that have never had the benefit of structured COBOL taught well", arguing that the issue was primarily one of training.<ref>{{Cite journal |doi= 10.1145/948176.948186| title=In defense of teaching structured COBOL as computer science| journal=ACM SIGPLAN Notices| volume=18| issue=4| pages=86–94| year=1983| last1=Tompkins| first1=H. E.| s2cid=33803213| doi-access=free}}</ref>

One cause of [[spaghetti code]] was the {{code|GO TO}} statement. Attempts to remove {{code|GO TO}}s from COBOL code, however, resulted in convoluted programs and reduced code quality.{{sfn|Riehle|1992|p=125}} {{code|GO TO}}s were largely replaced by the {{code|PERFORM}} statement and procedures, which promoted [[modular programming]]{{sfn|Riehle|1992|p=125}} and gave easy access to powerful looping facilities. However, {{code|PERFORM}} could be used only with procedures so loop bodies were not located where they were used, making programs harder to understand.{{sfn|Shneiderman|1985|pp=349–350}}

COBOL programs were infamous for being monolithic and lacking modularization.<ref>{{cite book | url=https://books.google.com/books?id=MJmJAwAAQBAJ&pg=PA4 | title=Beginning COBOL for Programmers | publisher=Apress | access-date=13 August 2014 | page=4 | first=Michael | last=Coughlan | isbn=978-1430262534 | date=16 March 2014}}</ref>
COBOL code could be modularized only through procedures, which were found to be inadequate for large systems. It was impossible to restrict access to data, meaning a procedure could access and modify {{em|any}} data item. Furthermore, there was no way to pass [[parameter (computer programming)|parameter]]s to a procedure, an omission Jean Sammet regarded as the committee's biggest mistake.{{sfn|Sammet|1978b|p=258}}

Another complication stemmed from the ability to {{code|PERFORM THRU}} a specified sequence of procedures. This meant that control could jump to and return from any procedure, creating convoluted control flow and permitting a programmer to break the [[single-entry single-exit]] rule.{{sfn|Riehle|1992|p=126}}

This situation improved as COBOL adopted more features. COBOL-74 added subprograms, giving programmers the ability to control the data each part of the program could access. COBOL-85 then added nested subprograms, allowing programmers to hide subprograms.{{sfn|Riehle|1992|p=127}} Further control over data and code came in 2002 when object-oriented programming, user-defined functions and user-defined data types were included.

Nevertheless, much important legacy COBOL software uses unstructured code, which has become practically unmaintainable. It can be too risky and costly to modify even a simple section of code, since it may be used from unknown places in unknown ways.<ref>{{Cite web|url=http://www.nakedcapitalism.com/2016/07/cobol-and-legacy-code-as-a-systemic-risk.html?imm_mid=0e6043&cmp=em-prog-na-na-newsltr_20160723|title=COBOL and Legacy Code as a Systemic Risk {{!}} naked capitalism|date=19 July 2016|language=en-US|access-date=23 July 2016}}</ref>