Spaghetti code

Spaghetti code is a pejorative phrase for source code that has a complex and tangled control structure, especially one using many GOTO statements, exceptions, threads, or other "unstructured" branching constructs. It is named such because program flow is conceptually like a bowl of spaghetti, i.e. twisted and tangled.[1] Spaghetti code can be caused by several factors, such as continuous modifications by several people with different programming styles over a long life cycle. Structured programming greatly decreases the incidence of spaghetti code.

History

An early reference that contributed to the term in 1968 was a letter by Edsger Dijkstra to the Communications of the ACM, published under the title "Go to statement considered harmful".[2] It focused on the disadvantages of the GOTO statement and how it contributed to an unstructured coding style. Dijkstra argued that the GOTO statement should be removed from programming languages, in favor of structured control flow statements.[3][4]

It is not clear when the phrase spaghetti code came into common usage; however, several references appeared in 1977 including Macaroni is Better Than Spaghetti by Steele published in Proceedings of the 1977 symposium on artificial intelligence and programming languages. In the 1978 book A primer on disciplined programming using PL/I, PL/CS, and PL/CT, Richard Conway used the term to describe types of programs that "have the same clean logical structure as a plate of spaghetti",[5] a phrase repeated in the 1979 book An Introduction to Programming he co-authored with David Gries.[6] In the 1988 paper A spiral model of software development and enhancement, the term is used to describe the older practice of the code and fix model, which lacked planning and eventually led to the development of the waterfall model.[7] In the 1979 book Structured programming for the COBOL programmer, author Paul Noll uses the phrases spaghetti code and rat's nest as synonyms to describe poorly structured source code.[8]

In a 1980 publication by the United States National Bureau of Standards, the phrase spaghetti program was used to describe older programs having "fragmented and scattered files".[9] The consequences of using goto statements in programs were described in a 1980 paper, which stated that it was perceived to be "evil".[10][11]

In the Ada – Europe '93 conference, Ada was described as forcing the programmer to "produce understandable, instead of spaghetti code", because of its restrictive exception propagation mechanism.[12]

In a 1981 computer languages spoof in The Michigan Technic titled "BASICally speaking...FORTRAN bytes!!", the author described FORTRAN as "proof positive that the cofounders of IBM were Italian, for it consists entirely of spaghetti code".[13]

Examples

Here follows what would be considered a trivial example of spaghetti code in BASIC. The program prints each of the numbers 1 to 100 to the screen along with its square. Indentation is not used to differentiate the various actions performed by the code, and that the program's GOTO statements create a reliance on line numbers. The flow of execution from one area to another is harder to predict. Real-world occurrences of spaghetti code are more complex and can add greatly to a program's maintenance costs.

1 i=0
2 i+=1
3 PRINT i; "squared=";i*i
4 IF i>100 THEN GOTO 6
5 GOTO 2
6 PRINT "Program Completed."
7 END

Here is the same code written in a structured programming style:

1 FOR i=1 TO 100
2     PRINT i;"squared=";i*i
3 NEXT i
4 PRINT "Program Completed."
5 END

The program jumps from one area to another, but this jumping is formal and more easily predictable, because for loops and functions provide flow control whereas the goto statement encourages arbitrary flow control. Though this example is small, real world programs are composed of many lines of code and are difficult to maintain when written in a spaghetti code fashion.

Assembly, scripting, and other languages

When using the many forms of assembly language (and also the underlying machine code) the danger of writing spaghetti code is especially great. Some scripting languages have the same deficiencies: this applies to the batch scripting language of DOS and DCL on VMS.

Nonetheless, adopting the same discipline as in structured programming can greatly improve the readability and maintainability of such code. This may take the form of conventions limiting the use of goto to correspond to the standard structures, or use of a set of assembler macros for if and loop constructs.

Most assembly languages also provide a function stack, and function call mechanisms which can be used to gain the advantages of procedural programming. Macros can again be used to support a standardized form of parameter passing, to avoid ad hoc global variables and the action at a distance anti-pattern.

Some widely used newer programming languages, such as Python and Java, do not have the goto statement,[14] and therefore strongly encourage structured programming.

LabVIEW, being graphical, provides a unique opportunity for developers to write spaghetti code that literally looks like spaghetti.[15]

The phrase "spaghetti code" has inspired the coinage of other terms that similarly compare program structure to styles of pasta. The general meta-phrase is "programming pasta".

Ravioli code

Ravioli code is a pejorative phrase for source code with lots of tiny, tightly-coupled objects. The tangled but explicit control structure of Spaghetti code is replaced with equally tangled but now implicit control flow using polymorphism. Overzealous separation and encapsulation of code can bloat call stacks and make navigation through the code for maintenance purposes more difficult.[16]

Lasagna code

Lasagna code, named in 1982 by Joe Celko,[17] is any program structure characterized by several well-defined and separable layers, where each layer of code accesses services in the layers below through well-defined interfaces. The analogy stems from the layered structure of lasagna, where different ingredients (for example, meat, sauce, vegetables, or cheese) are each separated by strips of pasta.

While these approaches sound positive, lasagna code is often rather derogatory term, applied for unnecessary excessive, insufficiently documented or otherwise poorly designed layered architecture. For instance, having mostly one implementation per interface may indicate that interfaces are used the wrong way.[18]

One common instance of lasagna code occurs at the interface between different subsystems, such as between web application code, business logic, and a relational database. Another common programming technique, alternate hard and soft layers (use of different programming languages at different levels of the program architecture), tends to produce lasagna code. In general, client–server applications are frequently lasagna code, with well-defined interfaces between client and server.

Lasagna code generally enforces encapsulation between the different "layers", as the subsystems in question may have no means of communication other than through a well-defined mechanism, such as SQL, a foreign function interface, or a remote procedure call. However, individual layers in the system may be highly unstructured or disorganized.

A similar layering may be seen in communication stacks, where a protocol (such as the OSI model) is divided into layers (in this case seven), with each layer performing a limited and well-defined function and communicating with other layers using specific and standardized methods. Such a design eases the evolutionary improvement of the entire stack through layer-specific improvements.

Again, while loosely coupled layering is generally desirable in a program's architecture because it makes objects at each layer more interchangeable with existing or possible future implementations, other types of changes to the code will actually increase in complexity as more layers are added and so an extensively layered architecture can be seen as an anti-pattern as well. Adding a new field to a UI view, for example, requires changing every object at every layer in the architecture that is required to have knowledge about this new field (generally the view itself, any underlying controller/presenter class, data transfer objects, SOA layers, data access objects or mappings, and the database schema itself). A quote usually attributed either to David Wheeler or Butler Lampson reads: "There is no problem in computer science that cannot be solved by adding another layer of indirection, except having too many layers of indirection". Similarly, Michael Padlipsky wrote that "If you know what you're doing, three layers is enough; if you don't, even seventeen levels won't help."[19]

See also

References

  1. ↑ Horstmann, Cay (2008). "Chapter 6 - Iteration". Java Concepts for AP Computer Science (5th ed. [i.e. 2nd ed.]. ed.). Hoboken, NJ: J. Wiley & Sons. pp. 235–236. ISBN 978-0-470-18160-7. Retrieved 2 January 2017.
  2. ↑ Dijkstra, E. W. (March 1968). "Letters to the editor: go to statement considered harmful". Communications of the ACM. 11 (3): 147–148. ISSN 0001-0782. doi:10.1145/362929.362947.
  3. ↑ Faulkner, Larry R.; Durbin, John R. (19 August 2013). "In Memoriam: Edsger Wybe Dijkstra". The University of Texas at Austin. Retrieved 20 August 2015.
  4. ↑ O'Regan, Gerard (2013). Giants of Computing: A Compendium of Select, Pivotal Pioneers. (London: Springer Verlag), pp. 91–92
  5. ↑ Conway, Richard (1978). A primer on disciplined programming using PL/I, PL/CS, and PL/CT. Winthrop Publishers. ISBN 0-87626-712-6.
  6. ↑ Conway, Richard; Gries, David (1979). An Introduction to Programming (3rd ed.). Little, Brown. ISBN 0-316-15414-8.
  7. ↑ Boehm, Barry W. (May 1988). "A spiral model of software development and enhancement". IEEE Computer. IEEE. 21 (2): 61–72. doi:10.1109/2.59.
  8. ↑ Noll, Paul (1977). Structured programming for the COBOL programmer: design, documentation, coding, testing. M. Murach & Associates.
  9. ↑ United States National Bureau of Standards (1980). ASTM special technical publication. United States Government Printing Office.
  10. ↑ "Electronic Design". Electronic Design. Hayden Publishing Company. 28 (14–19). 1980.
  11. ↑ Allen, Belton E. (1980). Tutorial, microcomputer system software and languages. IEEE Computer Society, Institute of Electrical and Electronics Engineers. Computer Society Press.
  12. ↑ Schwille, Jürgen (1993). "Use and abuse of exceptions — 12 guidelines for proper exception handling". Lecture Notes in Computer Science. Ada – Europe '93 (Proceedings). 688. Springer Berlin Heidelberg. pp. 142–152. doi:10.1007/3-540-56802-6_12.
  13. ↑ MTSBS (March–April 1981). "BASICally speaking...FORTRAN bytes!!". The Michigan Technic. College of Engineering, University of Michigan. 99 (4).
  14. ↑ Goto#Language support
  15. ↑ forums.ni.com
  16. ↑ http://wiki.c2.com/?RavioliCode
  17. ↑ Celko, Joe (January 1997). "The Future of SQL Programming". DBMS Online. Retrieved 2008-09-10.
  18. ↑ Reusable Software? Just Don't Write Generic Code. Jos De Jong (2015).
  19. ↑ Padlipsky, Michael (1985-01-01). The Elements of Networking Style. ISBN 978-0595088799.
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.