Spaghetti Code vs Lasagna Code

In an effort to streamline and homogenize code a number of design patterns and best practices have sprung up in the programming field. One of the ideas that has moved across programming disciplines is the vilification of long strands of meandering logic, or called spaghetti code. For many in the field the very mention will bring out an immediate negative response and, at times, a few nightmarish stories of maintaining such outdated systems. So what is so bad about spaghetti code, and what is a better alternative?

Spaghetti code is usually the result of multiple feature hacks. When a new piece needs to be added to an application there is no thought put into how it fits into the overall platform or how future updates can benefit from the code. Trying to trace back a logic flow involves a crazy hunt tracking down multiple function calls and included files. The worse cases of spaghetti code are located in large procedural codebases. On the side, if you're within an object-orientated system and there are random classes entwined with the application, you can always call it spaghetti with meatballs.

There are few obvious drawbacks with this type of code. Debugging and building new features borders is incredibly difficult. Bringing new developers and educating them requires excessive amounts of resources. However, there are positives to this type of programming. If every feature and logic path has its code thread, the chance of accidents are minimized (although spaghetti code is known to have many random branches and unexpected dependencies).

Lasagna code is another way to describe system architecture. Following the pasta naming convention, this type of code utilizes layers to separate functionality. A typical process will cross several layers, each one optimized for an individual simple task. Lasagna code is often used to describe overly-abstracted layer-based systems, although its usually put in a favorable light compared to the randomness of spaghetti code.

The positive attributes of lasagna code look like a direct opposite of spaghetti code. Chunks of logic can be shared easily across different areas of a platform in a DRY-esque manner. Each layer can be incredibly simple and easy to understand. New developers can be trained on individual layers. Optimizing and debugging can be simple if you can narrow down which layer and type of functionality needs to be updated.

Layering your code is not always the optimal solution, though. Lasagna code can act as slippery slope down to over-abstraction and an urge to create the perfect system. Small updates can reverberate through all areas of an application, creating an appropriate but disabling fear of touching fundamental areas of the code base. Tidying up a single layer can be a large undertaking with huge risks and small payoff.

So what do I think is better, lasagna or spaghetti? Easy question: lasagna (both in terms of code and dinner), but it's important to recognize the drawbacks. Also, it is important to note that there are many design patterns and practices outside of these two. Spaghetti code can be downright nasty, even if it does get the job done. Lasagna code can take longer to create but can push better development processes and lower the barrier of entry. Whatever you call it, just write clean code, code that can be easily understood and worked on by future developers, and if you're lucky no one will ever call you a spaghetti chef.