Can Someone Explain to Me Why It's Called "Spaghetti Code"?

Its a mess, all wrapped up and tangled, you can't tell where one noodle starts and another ends. Basically means the code is very unorganized and they can't tell what is where or how to fix it immediately.

I've been taking a programming course and spaghetti code isn't just a Riot thing

but it's basically when the wires of code "the strands of spaghetti" are extremely disorganised (like a plate of spaghetti), usually cause by the code having way too many "goto" commands that result in the code being extremely unreadable and difficult to fix. Basically where the usage of goto (which sends the program to different lines of code, for example goto line 3 would send the program to run what ever code is on line 3), which of course, having a lot of gotos everywhere would make for very messy, non-linear code.

I'm doubtful that the game client is that messy (but that's just my thought, since I don't actually know how the game runs) but it's a funny way to reference the games coding so I'm guessing it just stuck as a meme.

Imagine you have a car, and when you change radio stations, the headlights turn on. That's regular code.

Now imagine when you roll down your window, the wipers turn on and radio switches to that yodeling station. That's bad coding.

Finally imagine that when you shift in your seat, the brakes on one side seize up, the trunk pops and radio starts playing demonic-sounding static. That's spagetti code.

Because it's loose and slips around..... like spaghetti.

there are 3 types of code

spaghetti code

1. goto 3
2. end
3. print "this is my spagetti program"
4. goto 2

The execution goes though the program like a spaghetti string. Make no mistake, SPAGHETTI CODE IS THE BEST way to program and is actually how computers operate. But its unreadable for anyone who did not write it and even a single change can destroy it. (say you change "goto 3" to "goto 2" and everything stops working and good luck finding the error) This is very bad for bugfixing.

functions code

1. call FunctionSay("this is my function program")
2. end
3. code describing what "FunctionSay" does (printing)

this program separates stuff you WANT the computer to do, from stuff you tell the computer HOW to do. Still they are intertwined, as you pass the things from the WANT part to the HOW part, and that is source of some problems also.

object code

1. create Object MyObject
2. MyObject.say.greeting()
3. end
4. some complex code describing properties of "MyObject", in particular defines greeting as "this is my object program"

This program totally decouples the WANT and HOW parts, you just create an object with properties and then execute it like.. human.walk or human.sit, and don't actually care how its done. This is very easy to modify and separate workload in a team environment because they don't care anymore what the other team does. But there are problems with that approach too, that's why its not used everywhere.

http://i.stack.imgur.com/4laaY.jpg