Spaghetti Code

Code in which control flow is tangled up like Spaghetti.

...and one of those things that "everybody else does."

For a more "scientific", pattern-based approach to pasta, see the "BigBallOfMud" development model in PatternLanguagesOfProgramDesign v4.0. The same article is available online at http://www.laputan.org/mud/mud.html.

The opposite of RavioliCode.

Not quite as bad as ChineseNoodleCode? or RamenCode?. But worse than MacaroniCode?....

The term SpaghettiCode came into vogue with the invention of block structured programming languages - languages with if and while statements that executed blocks of code delimited with begin and end statements (or punctuation).

NiklausWirth proved that anything that could be coded could be coded as nested blocks controlled by "if" constructs and "while" constricts, and championed the idea that things should be coded in this way. That is, your if-goto statments should not branch just anywhere, but should respect a block structure of the code. Code that did not was "spaghetti code".

Then they invented ALGOL-60 and the other block structured languages, which formalised this idea of structuring your code. Kids these days are brought up with structured programming languages and don't know how bad we had it. Original BASIC, anyone?

-- PaulMurray

Does anyone else get the feeling that HyperText and URLs in web-based IT applications tend to become the Web designers' version of SpaghettiCode?

Yes! Every time I do ActiveServerPages. It seems like it's going back 20 years. -- sg

You should take a look at recent Smalltalk and Scheme web-services frameworks. By using continuations to model web interactions, it is possible (and easy) to separate displaying and logic on web applications: http://citeseer.nj.nec.com/graunke01automatically.html

To quote the Seaside webpage (http://www.beta4.com/seaside2/):

Its most unique feature is its approach to session management: unlike servlet models which require a separate handler for each page or request, Seaside models an entire user session as a continuous piece of code, with natural, linear control flow - pages can call and return to each other like subroutines, complex sequences of forms can be managed from a single method, objects are passed by reference rather than marshalled into URLs or hidden fields - while fully supporting the backtracking and parallelism inherent to the web browser.

(Perhaps this should be moved to a different page?)

-- CarlosScheidegger

Also known as Cpaghe++i code. [DriveBySlander alert]

Yes, spoken like a true Java weenie. We Know Who You Are.

Q. Who first introduced spaghetti code to the West?

A. Macro Polo.

--AndrewKoenig

WorstPunEver (also an anagram away from "Macro Loop")

Sometimes this term refers to the use of GoTos. However, sometimes it is used to describe code that one finds hard to read or grok. Outside of GoTo usage, there is no clear consensus definition or criteria that one can use to measure "spaghettiness". As somebody joked above, spaghetti code often is all code that is not our own because it was generated by minds that think differently than us. Calling somebody else's code spaghetti code is almost a sure way to start a FlameWar. Thus, it is recommended that you provide something more specific, such as "needs more descriptive variables", "factor these repeating parts into function calls", etc.

Overuse of callback listeners...

  for (Listener l : listeners) //Anyone and everyone.
    l.somethingHappened(); //Where does this go? Fire up the debugger.

...can create SpaghettiCode. This is essentially DynamicSpaghettiCode?, as an indeterminate number of "lines" can register themselves to be called from an indeterminate number of "gotos". The price of decoupling, I guess.

I see nothing wrong with a widget handling it's own events in most apps. Listeners seem silly in that regard, at least as the primary option/tool. (There's a discussion around here somewhere related.)

[In most properly-designed GUI applications, a given widget does handle its own events. Listeners, however, allow you to decouple widgets from the environment in which they are manipulated. This is useful for creating (for example) interactive GUI design tools that allow the designer to dynamically interact with live, working widgets -- perhaps populated with real data -- as the GUI is being built, without having to explicitly code the widgets to work with the GUI builder. They also allow you to write code that subscribes to a given event from a large quantity of widgets (such as detecting when an end-user has updated a complex form) without having to explicitly code each widget to broadcast or announce that the end-user has manipulated it. Thus, Listeners can reduce SpaghettiCode.]

Other instances of SpaghettiCode can include

overuse of events (excessive listeners - difficult to discern which listener is breaking your code)
overuse of abstractions and interfaces (no way to tell which concrete instance is being instantiated without debugging, and even then, the code path in one's own environment might not be the one that broke in production or QA)
excessive dependency upon config files (slight changes can drastically alter behavior in unexpected ways)

All of the above are based on good design patterns. These patterns are intended to be used in specific ways, and it's always possible to use them in such a way that they cause unpredictable results, sending the thread through nigh-chaotic paths through one's code.