Spaghetti code is something that all developers know is bad. They have an idea on how not to create it, but inevitably do. It’s like the governments definition of obscenity: you know it when you see it.

There are some good patterns and practices to help prevent spaghetti code, but I’m still itching to have a good definition of what spaghetti code is.  I’d like to show one way of understanding what makes spaghetti code by looking at software systems as fractal systems that contains layers of code.

Layers of Code

Most places that I’ve worked at as a developer have their code organized in a similar way. Most places have heard or used the Repository pattern. DOTNET shops have plenty of experience creating “client” code for communicating to SOAP or WebAPI endpoints. UI projects all now have “controllers” or “view models”.

These “types” of classes/code are different fractal layers within a system.  What I mean by fractal is that they look and act very similar but are at different levels in the system.

Dependency Segregation

Here is a simple example of types of classes that would be in a UI application (web or native) (dots representing classes):

Each level is a fractal layer: the classes look and act very similar, but each layer is a hierarchical level in the fractal system.  Views use Controllers, Controllers use Services, Services use Clients, etc…

Each hierarchical layer uses as a dependency a class from the lower fractal level.  The call stack starts to look like a tree, or root depending on how you view it.  Nature’s best pattern at work!

Spaghetti Code

Spaghetti code is code that has references or makes calls to the same or above levels within the fractal system.

In this outline, the call stack looks more like a snake than a tree.

Your code must fork, not snake!

This creates many problems, one being the high change of circular references. The other issue is that this will highly limit optionality on future enhancements or bug fixes. We can’t make changes to one controller without it affecting another controller without our knowledge.

Cross Same Level Communication

There will be many times that one will need to communicate across the same level classes within a system, and there are some great patterns for this: Pub/Sub and the Observer Pattern are a couple.

The two patterns have their differences, but the idea is the same. It provides a way for classes within the same fractal level to communicate via sending events.  This keeps all the classes highly decoupled and provides a way to not violate the fractal dependency segregation due to having a central messenger or event bus at a separate fractal level.

However, one can still violate the fractal dependency segregation if they were to publish events from one fractal level and read it in another.  Events need to be kept within the same hierarchical level.

Events need to be kept within the same hierarchical level.

Overview

The fractal dependency segregation description above is a simple way of viewing the hierarchy of your code to help prevent spaghetti code.  Spaghetti code is a call stack that is calling entities at the same or above level within the fractal system hierarchy. Communication between same level entities should use patterns such as Pub/Sub or the Observer Pattern.