スパゲティプログラム
命令型プログラミングでは、プログラムはコンピュータに対する手順書であり、プログラムに書かれた通りの順でコンピュータに対する指示(命令)が次々に出され、それをコンピュータが解釈することで動作していく。中間表現と仮想機械を利用する形態もあるが、最終的には機械語としてコンピュータが直接解釈可能な命令に変換される。メモリ上に存在する変数などによって管理されるプログラムの状態(ステート)を動的に変化させながら、プログラムに書かれた通りに文を次々に実行していく。基本的には上から下に辿る順でプログラム行が1文ずつ実行されていくが、行番号や何らかのラベルを指定して遠く離れた場所にジャンプする命令や、サブルーチン呼び出しと復帰など、遠く離れた場所にジャンプして別のコードを実行した後、また元の位置に戻る、といった命令もある。スパゲティプログラムというのは、規律のない不用意なジャンプの多用によって命令実行の順番が複雑に入り組んでいたり、プログラムの状態を管理するための変数が遠く離れた場所(プログラム全体のあちこち)で読み書きされていたりと、まさにスパゲティがこんがらがったような状態になったプログラムのことである。
スパゲティプログラムは、プログラムのテストを実施したり、内部動作解析やデバッグのためにプログラムをステップ実行によりトレースしたりすることが困難になる。結果として、プログラムのスムーズな開発や完成を妨げる。
並行処理や並列処理のために複数のスレッドを使用するマルチスレッドプログラミングでは、処理の流れが1つではなく、同時に並行動作する複数のスレッドが互いに協調し合う必要があり、不用意にスレッドを使うとスパゲティ化を招きやすい。マルチスレッドによる非同期処理は、従来とはまったく別の意味でのスパゲティコードをもたらす。スレッドを利用する際は、データ競合による未定義動作や競合状態による意図しない動作が発生しないよう、スレッドセーフを意識して慎重にプログラミングする必要がある。排他制御の作法を誤ると性能低下やデッドロックのような問題も発生する。特にマルチスレッドのバグはタイミングによって異常が発生したりしなかったりすることもあるため、シングルスレッドのプログラミングよりもデバッグの難易度が高い。
マルチスレッドプログラミングを簡略化し、コードの信頼性を向上するために、構造化並行性 (structured concurrency) と呼ばれる概念についても議論されている。
スパゲティプログラムを作り出す原因としてよく挙げられるのが、goto文の濫用である。(構造化以前の)BASICなどの言語にあるgoto文は、機械語やアセンブリ言語のアドレス指定ジャンプ命令に近い特性を持ち、無条件に指定した行番号の位置までジャンプする。これはサブルーチン(関数)やループなどの制御構文を利用した制御に比べ、処理の(素直な、上から下への)流れを混乱させる。離れた位置に書かれた行へ飛ばせるので、もちろんソースコードの可読性も低下させ、不具合や欠陥(バグ)を含んだコードを書いてしまう原因にもなる。
特に構造化されていないBASICは、各行に「行番号」があり、その行番号をジャンプ先として指定してジャンプするという原始的な機能だった。BASICにおいて、goto文はプログラム中のあらゆるところで登場し、プログラムがif文で条件分岐する際、goto文を使ってジャンプするということもよくあった。return文を持つサブルーチン機能もあるものの、GOSUBでサブルーチンに飛ぶためにはやはり行番号を指定する必要があり、goto文でサブルーチンの途中に飛ぶような危険なコードも記述可能だった。結果として、低品質なスパゲティプログラムが氾濫し、人々を悩まし、構造化以前のBASICは酷評されるようになり、BASIC自体が廃れてしまった。のちに全く別系統の、行番号やGOTO文を廃して構造化プログラミングを可能とした「構造化BASIC」が登場した。