While it may make for a delicious Italian dinner, one of the last things you want to hear about regarding your codebase is spaghetti. The idea that your code is as tangled as a plate of spaghetti is horrifying, but for a lot of developers, the idea is so abstract they can’t quite get a handle on it (or understand how to avoid or fix it). That’s why in this post we want to dive into what spaghetti code actually is, show you some best practices to avoid it, and (when it does happen) how to deal with it.
What is Spaghetti Code?
Spaghetti code is a nightmare, that’s what. Like we said above, the slang term gets its name because, like a giant tangle of spaghetti pasta, if you pull on one strand (piece of code), it ends up getting entwined in another and another and another, until it or all of the tangled pieces break.
For example, think about the !important property in CSS. It’s incredibly powerful, letting a designer override inherited styles and have control over any particular element without having to recode the entire stylesheet. However, when they (or future devs and designers) need to adjust something else, they might add another !important tag to override the previous one. And so on. But if you were to go back and remove or alter any of those in that stack, any number of styles on the page might break.
Which is what we’re trying to avoid.
Best Practices to Avoid Spaghetti Code
1. Develop Coding Standards
The number one way of preventing spaghetti code is to create and coding standards within your organization or project. Coding standards are what make projects like WordPress possible. Thousands of developers have worked on WP Core, but the WordPress Coding Standards have made it so that they’re all working within the same guidelines and performing the tasks within the same parameters in the same way.
Coding standards are just rules you enforce. They keep everyone’s code working in the same pattern so that errors are easy to find and fix, and that future devs (or even you or your current team) can know exactly what each line of code does as efficiently as possible. If Susan’s code isn’t passing its tests, it doesn’t get in. If Janine’s code doesn’t have tests to run, the pull request is denied. Perhaps Daniel doesn’t use divs on his most recent pull request. No merge until things are divided up.
Also, some of the original codebases that were plagued by spaghetti code were older languages without functional logic. The code wasn’t function-based, and therefore, various logic was directed at specific lines within the code. With small projects, this isn’t too bad to navigate. When you begin scaling projects, having direct references to specific files and lines of code can impede that development. Files can go missing, lines can get deleted or misnumbered. And debugging it to find out just which strand of the spaghetti got pulled can take hundreds of person-hours. Having coding standards can keep this sort of mess from happening as often.
So by developing standards, you have very effectively lowered the chances of your having a repository of spaghetti code. If you want to learn more about coding standards in general, GeeksforGeeks has an excellent guide.
2. Follow a Style Guide
In addition to coding standards, having a style guide to follow can also keep your code from getting too tangled. While it may sound similar in theory, the two are very different. Coding standards are there as enforceable rules your devs follow in order to keep the code working efficiently. These can change from project to project or from team to team within an organization.
A style guide, however, is generally written on a language-by-language basis, providing a series of best practices for making the code readable and functional. For example, Airbnb created one of the best style guides for React.js out there. If you’re not a React dev, then it means next to nothing. But for React developers, looking at this can give a real help in how your code should be structured and written to make it as accessible for future developers to sort through as possible.
A style guide, in contrast to general coding standards, aren’t necessarily enforceable rules. They’re suggestions to make the code more uniform, which makes the code easier to read. Which prevents spaghetti code because you know precisely what strand you’re pulling on at any given time.
3. Comment Your Code
Code comments are maybe the easiest way of preventing your repositories getting filled with spaghetti code. When you write something, create a comment about what it does. If it’s a complicated function or snippet, explain what the logic does and why it matters.
You run into a couple of issues relying on code comments to prevent messes, though. The first being that it adds a lot of extra time to projects. When you’re crunching to hit a deadline or make sure a feature is working correctly, it’s not always front-of-mind to write out a detailed explanation of it. And if you start out commenting and fall off mid-project or the next dev doesn’t continue? That’s a big plate of spaghetti.
Others get overwhelmed by the idea of commenting their code — or learning to comment their code if they haven’t done it before — because of the sheer volume they develop. Which is entirely valid. But even if you comment occasionally on important (or even precarious) lines or snippets, you’re going to save someone, potentially yourself, the trouble of pulling on it in the past, trying to figure out what it does.
Spaghetti code is a nightmare, I repeat. Spending countless hours trying to figure out what line of code was changed in a gigantic repository is one of the worst parts about being a developer. Debugging is fine(ish). Debugging and not knowing where to start or what’s even remotely causing the problem is not. But if your team sets up coding standards, follows a language style guide, and has even a minor code commentary policy, there’s a very high chance that your digital plate of spaghetti will be far less tangled up than it otherwise would be.
What do you do to prevent spaghetti code?
Article featured image by Donnay Style / shutterstock.com