Spaghetti code
Spaghetti code is a pejorative term for software - source code , the muddled control structures has. An indication of this can be the use of jump instructions (such as GOTO
), whereby one would arrive at the same goal without jumps. Any piece of source code that is confused and difficult to understand even for experienced programmers can be described as spaghetti code. Software written this way doesn't have to work badly; spaghetti code does not necessarily mean that the individual programming steps are not commented properly.
Spaghetti code can have different causes. Often inexperienced programmers tend to “just start programming”, which inevitably creates spaghetti code. The repeated subsequent expansion of the source code without refactoring can also lead to confusion and thus to spaghetti code .
Compared to clearly structured source code, spaghetti code has a significantly poorer maintainability, i.e. also increased test and maintenance costs. In addition, if the requirements are similar, spaghetti code can usually be reused much more poorly or only with great effort.
Programming example
The following program , created in the programming language BASIC , outputs the numbers 1 to 10 together with the respective square of the number on the screen. The two consecutive GOTO
statements make up the spaghetti code: They are generally not necessary, and they make it difficult to read for those who want to understand the code. In practice, spaghetti code is often much more complex.
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 Fully Completed."
70 END
In plain language the program says: Start at 0, then always increase by 1. Bring the result on the screen, together with its square. If the number is greater than or equal to 10, jump down. Otherwise jump to the beginning. Finished.
The following program does the same thing, but gets by without the two jumps. It is also shorter and therefore more elegant. Paraphrased it works like this: Start at 1 and go to 10, bring the respective number onto the screen, along with its square. Get the next number from the pool. Finished.
10 FOR i = 1 TO 10
20 PRINT i; " squared = "; i * i
30 NEXT i
40 PRINT "Program Fully Completed."
50 END
But there are other signs of spaghetti code. The GOTO
jump in the first program is still possible, but can lead to the following:
10 CLS
20 i = 0
30 i = i + 1
40 PRINT i; " squared = "; i * i
50 IF i >= 10 THEN GOTO 70
60 GOTO 30
70 PRINT "Program Completed."
80 INPUT "Do it Again (j)"; sel$
90 IF sel$ = "j" THEN GOTO 10
100 END
This use of GOTO
mostly leads to jumping back and forth between program blocks and thus causing real spaghetti code chaos. This doesn't just apply to the GOTO
instructions. Like to be with IF
in several blocks -Blöcken with IF
, FOR
or contain other sub procedures that caused a "clip chaos" as the following program based on IF
, FOR
and GOTO
clarifies:
10 FOR ia = 1 TO 10
20 IF ia = 5 THEN
30 FOR ib = 1 TO 10
40 PRINT "LOOP:";ia;" SUB LOOP:";ib
50 IF ib = 8 THEN GOTO 80
60 NEXT ib
70 END IF
80 PRINT "SUB LOOP:";ia;" END"
90 NEXT ia
100 END
This example is still manageable, but if you make larger jumps in several levels, you end up with a source code that at some point is no longer transparent even to the writer himself.
As a programmer, the greatest danger of producing spaghetti code yourself arises when you use a programming language that you do not yet understand or the commands for simple loop control are missing, e.g. B. in many assembly languages . Then it is essential to work with jump commands, where you can quickly lose track of things. The best example of the purest jumps is a finite automaton .
It is generally recommended to divide the code into small, manageable units (methods, functions) and to reuse the same parts. It can therefore be an advantage to sketch the ideas for the programming on paper and then to create the source code.
Programming paradigms
Different programming paradigms provide different means of avoiding spaghetti code . The object-oriented programming , for example, has to separate code from classes and class boundaries to distribute and reuse across different ways. However, spaghetti code can only be avoided by consistently adhering to the paradigms of object-oriented programming. In particular, adherence to the principles of object-oriented design , correct use of design patterns and domain-driven design prevent spaghetti code.
See also
- McCabe metric - a metric that spaghetti code can reveal
- Big Ball of Mud - architecture anti-pattern similar to spaghetti code
- Technical guilt
Web links
- Software Development AntiPatterns: Spaghetti Code (English)
- Spaghetti code in the Portland Pattern Repository
- Spaghetti Code: Detangling Life and Work with Programmer Wisdom (English Edition)
Historical
- US Army programmer husband rewiring a program on an IBM 407 in 1955.
- Computer course from the same time at Columbia University.