Spaghetti Code

Letter to the Editor
CROSSTALK, Journal of Defense Software Engineering

The mention of “a feast of spaghetti code” (“Computer Collectives,” CrossTalk, April/May 1992) prompted this response:

Nearly every software professional has heard the term spaghetti code as a pejorative description for complicated, difficult to understand, and impossible to maintain, software. However, many people may not know the other two elements of the complete Pasta Theory of Software.

Lasagna code is used to describe software that has a simple, understandable, and layered structure. Lasagna code, although structured, is unfortunately monolithic and not easy to modify. An attempt to change one layer conceptually simple, is often very difficult in actual practice.

The ideal software structure is one having components that are small and loosely coupled; this ideal structure is called ravioli code. In ravioli code, each of the components, or objects, is a package containing some meat or other nourishment for the system; any component can be modified or replaced without significantly affecting other components.

We need to go beyond the condemnation of spaghetti code to the active encouragement of ravioli code.

Raymond J. Rubey
SoftTech, Inc.

Plain text version

This one is contributed by Luca Nanetti:

  • Pure Java code: zuppa di fagioli code (italian for “beans soup”);
  • Internet apps with HTML, XML, etc, plus Java things: pasta e fagioli code (italian for “beans soup with pasta chunks”);
  • Bad OOP programming—few huge and absurdely complicated objects: canederli code (two big boiled balls of bread, eggs, milk and meat; very good!)
  • Bad OOP programming—a confusing lot of very, very little objects all interacting together: risotto code (rice);
  • Monolitical, non-object-oriented, non-procedural, non-structured code, but so wonderful, so good, so brilliant that it glows like a big bright yellow sun: polenta code.