DEV Community

Cover image for How to avoid dry spaghetti code

How to avoid dry spaghetti code

Patrick Rodrigues
・2 min read

I've been learning software development for over a year now, I started by learning Python and it evolved into JavaScript, learned a few frameworks, libraries, built a few websites, some servers and today I stand looking at how I've been writing code, code I wrote thinking it was readable and somewhat maintainable.

Well, I've come to the realization that I was wrong.

This realization occurred to me when I got into Game Development, learning C#, an object-oriented language.

I soon started to notice that at some point my code would become entangled like a sticky plate of dry spaghetti. Elegant from far away, yet inflexible and unfixable without some serious work.

Serious work was done, I started analyzing the code from my other projects, and then it hit me, my non-game projects take longer to arrive at a dry spaghetti stage but eventually it gets to the point when I have no idea what is going on.

Why does code become dry spaghetti?

There is one recurring pattern and one that is often overlooked or excused by stating that code serving a homogeneous result should be kept together.

We mix data with functionality, now don't jump the gun, I agree that to some very particular and obvious instances, yes it acceptable to do that. However, in bigger projects, I believe that segregation of data and functionality is a good way to keep your code readable, compartmentalized and most importantly maintainable.

A good example is JavaScript, where objects can store functions and it kind of imitates a class. However, by bundling the data and the functionality together, you're giving your object more than one reason to fail.

A class should only have one reason to fail

If it does one thing and one thing only, it will only fail because of that one thing.

Now, that doesn't mean you are going to create an object or a class with a single property that is not what I'm trying to say.

You have to take a step back and ask yourself, what am I trying to accomplish? what is the goal of this class, object, or even of this functional component? Is it doing more than one job?

If it is doing more than one job, then you probably need to separate it, by doing so, not only you're making it more maintainable, debuggable, but also reusable.

This also doesn't mean you can never bundle data and functionality together, there are millions of examples when this is okay. The relationship is complicated but with proper thought, it will be unbreakable.

Now, I understand if this is a bit hard to read and understand, I'm still trying to understand this myself and trying to explain is one of my ways to understand this better, but doesn't mean I've explained and written it in the best way possible.

If you think that there are things that could be explained better please leave me some feedback! I would love to learn with my readers.

Discussion (1)

temitopeakinsoto profile image
Temitope Akinsoto

Great article! Concise and easy-to-understand. It would be awesome if you could attach some code snippets to add more clarity and context. Thanks for sharing.