“Spaghetti code” is a well-known phrase for software with tangled logic, especially legacy code with goto
statements.
The term “lasagna code” is not nearly as common. I first heard it used to describe code with too many architectural layers. Then I found the following older reference to lasagna code with a different slant on the term.
Lasagna code is used to describe software that has a simple, understandable, and layered structure. Lasagna code, although structured, is unfortunately monolithic and not easy to modify. An attempt to change one layer conceptually simple, is often very difficult in actual practice.
Since “lasagna code” has a different usage, I propose the term “baklava code” for code with too many layers.
Baklava is a delicious pastry make with many paper-thin layers of phyllo dough. While thin layers are fine for a pastry, thin software layers don’t add much value, especially when you have many such layers piled on each other. Each layer has to be pushed onto your mental stack as you dive into the code. Furthermore, the layers of phyllo dough are permeable, allowing the honey to soak through. But software abstractions are best when they don’t leak. When you pile layer on top of layer in software, the layers are bound to leak.
This immediately made me think of some of the WSGI apps I’ve been digging through lately. It’s a useful and conceptually cool standard, but I’m finding that it’s also very easy to abuse.
If spaghetti, lasagna, and baklava are metaphors for bad programming, then what food represents good programming?
And to answer my own silly question: How about Mexican food. Seven basic ingredients served up in a multitude of different ways depending on the dish to be served (or task to be coded).
I like the Mexican food analogy, but I immediately thought of a hamburger: You’ve got the meat (the interesting code that the program is all about), the buns (a convenient, portable UI), and the toppings (interchangeable functions for pre- or post-processing). It works really nicely for the kind of code that I end up writing (data analysis/machine learning), where there’s one key idea that the whole algorithm is based on, with a whole lot of necessary but less-important code that wraps it.
Reminds me of the CGAL code base…
I’m disappointed you didn’t stick with the Italian theme; something that conjours up images of chaos in my head
Oh man, this reminds me…
One time, I had to work on some guy’s web-based scheduling application that he wrote in Perl. I’m something of a Perl guru (although experiences with other peoples’ Perl code have led me to avoid the language now), but wow. There were like ten layers of abstraction in the stupid thing, so it took me days to figure out where the real work was being done. The dude who wrote it was an eccentric genius, but his program was horribly over-engineered to the point of being unmaintainable. It felt like it was written so that if you wanted to, you could set it up to work on a completely different (non-web) interface, which was completely outside of the program’s design requirements.
So yeah, Baklava code. Excellent analogy. :)
When talking to my students, I use the term of MacDo Code.
More international than Baklava, and more dangerous too.
A coworker coined the term ravioli code for systems without a recognizeable organization of its class structure: just plenty of objects in tomato sauce.
I think the pun about baklava leaking is a bit of a non sequitur. ISTM, leaks (a kind of bug) are orthogonal to the amount of abstraction of a given piece of code. If the code has “too much” abstraction, that doesn’t mean that it is buggy, or leaks resources. I think the top-down approach can work well, depending on the objective, and the programming language of the implementation, although it sometimes results in (too) many layers of abstraction. It depends what you are doing.
I like to eat baklava but don’t like to fix bugs in baklava code…
VIPER may be a great example of this.
The way I put it is: “Premature indirection is the root of all evil.”