Spaghetti code

Spaghetti code looks twisted and tangled, and like the eponymous bowl of spaghetti, following the course of any one strand through the whole is extremely difficult.

Spaghetti code is a pejorative term for source code that has a complex and tangled control structure, especially one using many GOTOs, 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. Spaghetti code can be caused by several factors, including inexperienced programmers and a complex program which has been continuously modified over a long life cycle. Structured programming greatly decreased the incidence of spaghetti code.

History

The term spaghetti code was used in 1963 by the United States Air Force to refer to its practice of using Italian terminology to improve communications clarity.^[1] 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",^[2] a phrase repeated in the 1979 book An Introduction to Programming he co-authored with David Gries.^[3] In the 1993 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.^[4] In the 1979 book Structured programming for the COBOL programmer, author Paul Noll uses the terms spaghetti code and rat's nest as synonyms to describe poorly structured source code.^[5]

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

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.^[9]

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".^[10]

Examples

Below is what would be considered a trivial example of spaghetti code in BASIC. The program prints each of the numbers 1 to 10 to the screen along with its square. Notice that 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. Also observe the less easily predictable way the flow of execution jumps from one area to another. Real-world occurrences of spaghetti code are more complex and can add greatly to a program's maintenance costs.

10 i = 0
20 i = i + 1
30 PRINT i; " squared = "; i * i
40 IF i >= 10 THEN GOTO 60
50 GOTO 20
60 PRINT "Program Completed."
70 END

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

10 FOR i = 1 TO 10
20     PRINT i; " squared = "; i * i
30 NEXT i
40 PRINT "Program Completed."
50 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 and script languages

When using the many forms of assembly language (and also the underlying machine code) the danger of writing spaghetti code is especially great. This is because they are low-level programming languages where equivalents for structured control flow statements such as for loops and while loops exist, but are often poorly understood by inexperienced programmers. Many 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.

Programs written in higher-level languages with high-level constructs such as for loops (as in the second example above) are often compiled into assembly or machine code. When this process occurs, the high-level constructs are translated into low-level "spaghetti code" which may resemble the first example above in terms of control flow. But because compilers must be faithful to high-level constructs in the source code, the problems that plague relatively unstructured languages like BASIC do not haunt higher-level languages. It does, however, mean that debugging even mildly optimized code with a source-level debugger can be surprisingly confusing.

Related terms

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

Ravioli code

Ravioli encapsulate hidden content, a goal of object-oriented code

Ravioli code is a type of computer program structure, characterized by a number of very small and (ideally) loosely coupled software components. The term stems from the analogy of ravioli (small pasta pouches containing cheese, meat, or vegetables) to modules (which ideally are encapsulated, consisting of both code and data). While generally desirable from a coupling and cohesion perspective, overzealous separation and encapsulation of code can bloat call stacks and make navigation through the code for maintenance purposes more difficult.

Lasagna code

Lasagna code has many layered components, much like the filling and pasta of its namesake.

Lasagna code, a term coined in 1982 by Joe Celko,^[11] refers to a type of 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. Also known as "onion code" because one often cries when opening so many layers.

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 Structured Query Language, a foreign function interface, or 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".

Spaghetti with meatballs

Spaghetti with meatballs code often speaks Java (meatballs) with a C (spaghetti) accent.

The term "spaghetti with meatballs" is a pejorative term used in computer science to describe loosely constructed object-oriented programming (OOP) that remains dependent on procedural code. It may be the result of a system whose development has included a long life cycle, language constraints, micro-optimization theatre, or a lack of coherent coding standards.

In some languages, OOP features are available only in later specifications. Notable examples of this include Visual Basic and PHP. Other languages, such as C, rely on function pointers to simulate OOP — still requiring the underlying procedural code to which they point.

Using OOP does not necessarily prevent a class's code from becoming spaghetti-like. In this parlance, "spaghetti" describes twisted, tangled and unstructured code, while "meatballs" denotes the use of class structures (i.e. objects).

Macaroni code

Macaroni code contains small pieces of two or more languages mixed together.

By analogy to macaronic language, macaroni code mixes two or more programming languages together in a single document. Server-side scripting languages such as Active Server Pages and PHP are explicitly intended to be embedded in HTML code, and HTML in turn is designed to have CSS and JavaScript embedded in it, and since server-side scripting languages frequently have SQL queries embedded in them as well, it is not difficult to use four or more languages in a single document, as shown in the "Hello World" example below:

<!DOCTYPE HTML>
<html>
<head><title>Macaronic Code</title></head>
<body>
    <?php
        $ip = $_SERVER['REMOTE_ADDR'];
        $dbh = new PDO('mysql:host=localhost;dbname=mydb', 'username', 'password');
        $statement = $dbh->query("SELECT lastlog FROM logins WHERE ip = '$ip'");
        $row = $statement->fetch(PDO::FETCH_ASSOC);
        $dbh->query("INSERT INTO logins VALUES ('$ip', CURRENT_TIMESTAMP) ON DUPLICATE KEY UPDATE lastlog = CURRENT_TIMESTAMP");
    ?>
    <p>Hello, <?php print $ip; ?>.</p>
    <script>
        var lastlog = "<?php print $row['lastlog']?>";
        if (lastlog > "") alert("You last visited "+lastlog);
        else alert("You've never been here before.");
    </script>
</body>
</html>

The above example^[12] uses SQL within PHP, PHP within HTML, PHP within JavaScript, and Javascript within HTML.

Because macaroni code can be difficult to read and maintain, particularly for people who do not know all of the languages used, open-source projects frequently take pains to isolate the various languages from each other in separate files. The above example could be rewritten as four separate files (.html and .js sent to the browser and .php and .sql remaining on the server), but the JavaScript would need to send an AJAX request to the PHP script to retrieve the values of the two variables it needs to complete the page. Loading the page would thus require three HTTP requests (for the .html, .js, and AJAX) instead of just one for the file of macaroni code.

See also

• International Obfuscated C Code Contest: A competition to produce pleasingly obscure C code.
• Write-only language

References

This article is based on material taken from the Free On-line Dictionary of Computing prior to 1 November 2008 and incorporated under the "relicensing" terms of the GFDL, version 1.3 or later.

External links

• Go To Statement Considered Harmful. The classic repudiation of spaghetti code by Edsger Dijkstra.
• We don't know where to GOTO if we don't know where we've COME FROM by R. Lawrence Clark from DATAMATION, December, 1973
• Refactoring Java spaghetti code into Java bento code separating out a bowl full of code from one class into seven classes
• Objects and Frameworks – Taking a Step Back by Brian Rinaldi