The Quest to avoid Spaghetti Code
I have become Spaghetti, Destroyer of Code
Programming can be a mentally draining task. Programmers have a goal to create a feature in a piece of software, then they have to plan out how to implement that feature, and then finally they carry out that plan.
Depending on the experience of the programmer and the amount of time available, there is usually one constant: Spaghetti Code.
For those unaware, Spaghetti Code is basically when the structure of a program follows no clear guidelines and is interconnected in all the wrong places. I think the perfect analogy is the virtual equivalent of tangled Christmas lights.
Even looking at the above image makes me want to cry.
Needless to say this is bad; but how bad?
Well in programming, we often plan out our code structure into Classes. In short, a class is basically a template of an object. A very vague description requires an example or two.
We can have a class of a dog; that class has code everything to do with Dogs, such as how to Bark, what breed they are, and perhaps their sex. Another example is a Car, which has code for Accelerating, honking the horn, and even what colour it should be.
Anyway, we make many of these classes. We make classes in order to separate concerns into their own bubbles. A dog should only have code related to the dog; nothing more, nothing less. Failure to comply means that classes will have no cohesion within themselves; unrelated code put in the wrong places, leading to possible questionable connections between classes. This would lead to having to call unrelated classes in order to perform unrelated tasks. A dog should not care who or what can pet them for example.
If we have these interconnections, programmers will have to make mental notes, or in the worst case actually write notes to describe where unrelated functions can be found in unrelated classes. This sounds stupid, but having to think too much unnecessarily to find where all your code is is baaaaaaaad. Imagine if I said “You can find the TV in the living room but the power point is actually in the kitchen behind the coffee maker.” Sure you’d get used to it, but the living room should have NOTHING to do with the kitchen! You shouldn’t even be THINKING of the kitchen.
One might ask, instead of having multiple interconnected classes, why not have one big class, also known as a God Object? Well that is almost as worse as having too many unrelated functions in classes. I can explain this with this link and a question; what would it be like to go through this file and find the function that has a bug in it?
That’s pretty much a simple high level overview on how important it is for programmers to avoid Spaghetti Code at all costs.
My Experience avoiding Spaghetti Code
It is very easy to talk about how bad Spaghetti Code, but how easy is it to avoid it?
I think this is a good time to explain my…..very painful experience of trying to avoid it myself.
This year I and an artist had to make a major project in the form of a game for our last subjects at university. You can play said game here.
The game is basically a turn based strategy game where you choose a fictional ideology, with which you take over the world. You have to compete against other ideologies which are controlled by AI, and you win once every country follows your ideology.
This is a very, VERY basic explanation of the game, if you want more detail have a look at the instructions in the game itself.
Anyway, a game with this concept can be complex, particularly mechanically. As lead programmer of the project, I wanted to use this opportunity to learn how to make a complex game in a way in such a way where Spaghetti Code is minimised, and easily extendable.
So how’d that go?
Over the course of 24 weeks. I had to restart development of the game 5 times.
The art assets were kept constant across all iterations, but the code was thrown out.
So, what the heck happened? Why was it so hard to stick to one iteration?
Learning, learning, learning.
One major problem was having too many classes with not enough of data to justify their existence. For example I would have a class called “Country”. So far so good, but instead of having fields for the name or population, there were be a class called “Details”. So to access the name of a country, I need to get the country, then the details, then the name, instead of getting the country, then getting the name.
Furthermore, I always sought to create the shortest possible files that still gets the job done. Generally speaking, I tended to avoid going past 200 lines of code at all costs. A good idea, but it should not override everything one does for the program.
Another major problem was trying to make a coding ecosystem that is self reliant. Basically every class doesn’t rely on another class. If you’re a programmer, you know that that’s literally impossible to do in an efficient manner. The fix to this is to follow the high-level, low-level structure. Try to make low-level classes (classes that do the work) as self reliant as possible, and the high-level classes (the managers) rely on the worker classes to get stuff done.
I fell into that 2nd problem, and it fucked me up.
Why is this bad? The main problem is that now I can’t easily control the flow of the game. If you hit “New Game”, the game starts. What’s the problem here? Well I can’t change HOW the game starts. I can’t set up all the actors in a specific way without rewriting entire sections of code, and I can’t even create custom scenarios. It was a mess!
But it was great that this happened. You can read, read, and read all the ways to structure your programs in an effective manner to avoid Spaghetti Code, but nothing teaches you more than messing up yourself.
I’m very happy with what we did with the game. It has a lot of problems, but it was such an enlightening experience for me and the artist. I hope one day to remake the game in a more effective form.
Closing Comments
Spaghetti code sucks. It sucks so much that I thought it was a constant in every programming assignment, which made me reconsider my intentions to pursue programming. However, even though it can be difficult, we can reduce Spaghetti Code in various creative ways, making it easier for us to create programs without wanting to pull our hair out.
If you’re interested in methods on how you can reduce the chances of Spaghetti Code, read up on Object Oriented Programming and the Solid Principles. you don’t need to follow the rules themselves, but they should give you ideas on how to best structure your code.
See you next time!
