A Formal Theory of Spaghetti Code
nickdrozd.github.io
nickdrozd.github.io
People usually think it is a good idea to use flags. They create a flag to store states of entities and think the problem is solved. Actually it sometimes duplicates the number of possible new problems.
I once tried to convince a friend not to use it. In a part of the code, I asked him: "Look, how can you guarantee that the states of the flags are consistent here?", he then added code just before the line to check for consistency of the flags. I then said that if the flags fell into an inconsistent state, then it should be fixed there, not when they are checked. He tried another fix: created "set methods" for each of the flags, each method called a function "checkFlags" which detected inconsistencies in the flags and automatically set them to a consistent state.
I continued: "Look, every time you add a new flag you will have to check this function and infer, among possible combinations, which are valid and which are not. If you need states, use an enumeration with few states all of which are consistent."
That is the problem with flag-oriented programming: each new flags doubles the number of possible states and it is very complicated to guarantee consistency between them considering all possible combinations and temptation to just add, set and check a new flag when writing code.
A physicist is showing their friend the computer scientist a thermos.
"This thing is so cool: you can pour something hot into it, and no matter how cold it is outside it stays hot". The friend is duly impressed.
"But that isn't all: you can pour something cold into it, and no matter how hot it is outside it stays cold"!
Now the computer scientist is puzzled. "But how does it know?"
Code like this is the bane of my existance.
The thermos doesn’t have a toggle (flag) on the outside that the operator sets to “hot” or “cold”. If you want to know you look. And instead of giving it a “hot mode” and “cold mode” you just build it to prevent mutation of the contents.
Likewise its weight or fill level: just look. Having flags is extra work keeping them up to date plus worrying about what to do when they are wrong or in an unexpected combination.
But people write code that way all the time. I do my best to avoid hiring them.
Labeling comments would enable you to filter out stuff you're not interested in reading, but I don't think a separate page is the answer.
Note the statement 'given Turing machine program'. It doesn't seem to be scoped to only busy beaver programs. Also note the author's different usages of 'spaghetti code' and the 'Spaghetti Code Conjecture' indicating the discussion of each being different topics. This is further noted by the fact that the author brings the conversation back to the 'Spaghetti Code Conjecture' by writing "With all this in mind, we can restate the Spaghetti Code Conjecture formally: the control flow graph of (sufficiently long) Busy Beaver programs ought to be at least partially irreducible."
With all that said, it seems the original commentator in this thread was discussing the definition of spaghetti code ("In particular, a graph that cannot be reduced at all can be considered utter spaghetti and a graph that can be eliminated completely can be considered thoroughly well-structured.") in relation to the states of a program. Building on the fact spaghetti code can (and has) been observed by the original commentator, they related the discussion of states to the development practice of using multiple flags (which leads to various states in a program)
This problem is amplified further because flags can come in so many different shapes and sizes:
- Rollout: binary on/off, percentage rollout, beta group rollout, single user rollout, etc.
- Control plane: eg. emergency shut off valve for the caching layer, switch that controls routing, etc.
- Multi-valued or numeric: ie. not just true/false, typically combined with A/B testing
Conflating these can lead to extremely messy code. Each of these cases deserves its own special type of treatment.
Rollout flags should have a self-destruct or mechanism that strongly encourages engineers to remove them as soon as they're no longer used.
Control plane stuff shouldn't really be mixed with feature flagging at all. It would be dangerous to remove them, and regularly vetting the states should be a necessary requirement for any type of disaster recovery assurance testing.
I really appreciate your call to represent these states as an enumeration. Capturing the flag states at the start of a request and then determining the proper bucket helps to make the problem more concrete. Engineers can then better reason about the explosion of states and the impact to control flow.
Ultimately, I think flagging is one of those "hard problems" that comes with the job territory. You don't want to throw the technique out entirely along with the bath water, because it has plenty of justifiable benefits. There are best practices and proper hygienic steps we can take to make the use of flags easier on ourselves.
You don't want your flag combinations contributing to invalid responses, or worse, persisting invalid states. (A well engineered model will have protections in place, but good flag hygiene helps.)
[1] I've found them in service discovery, monkey patched into 3rd party libraries, load balancer code, etc. Flags get used everywhere.
Flags work brilliantly when the states are independent and there is no such thing as an inconsistent state... the moment you have strange interdependence you lose all the benefits.
extremely hard for test coverage. but google prefers it over compile-time configs for easier upgrades and legacy handling.
even compile-time configs ("define explosion") are almost impossible to cover as testing is exponential.
“Cyclomatic complexity” is as old as the hills, but attempts to count the paths through the code from a begin state to and end state. According to Wikipedia it’s similar to “circuit rank” which is the minimum number of edges to remove in order to break cycles. That smells like it’s related to this graph reduction thing but I lack intuition into this problem.
Actually, I have a hunch that every program that is reducible in the standard compiler sense is also reducible in the sense of the article, but the converse does not hold. 1 -> 2 -> 3 -> 4, 1 -> 3 -> 2 is irreducible in the compiler sense (there is a loop with two entries) but reducible in the sense of the article (first merge 2 and 3, then delete self loop, an acyclic graph remains which is trivially reducible).
There's nice CC visualizers that can show you at a glance areas that have higher complexity. Sometimes that complexity is related to the problem domain, but sometimes it comes from overhead of poor system architecture.
I think your hunch is on point, I think because the author conflates running time of a busy beaver with benchmarks of programmatic coupling and cohesion.
Busy beaver algorithms are single-purpose programs. An eCommerce website is layers upon layers of interrelated modules and functions.
I get where they're going, reducing a problem space down to its simplest representation is ideal. I just don't on first pass understand how busy beaver accomplishes this.
In a 2-symbol TM, there are at most two outgoing edges in a state. If you remove the self-reference, you're left with just one. That seems to remove too much of the hidden complexity.
I suppose the thinking behind it is "a loop is not spaghetti code", but a loop in higher level language rarely translates to a single state moving to itself.
OTOH, it's possible to write spaghetti-code in a system that only has while loops and if-then-else by simply having very complex conditions, and modifying the variables on which they depend at seemingly unrelated points in the code. After all, both are TM complete.
> It’s even been proved that a Collatz counterexample must have certain striking properties, like an enormously long orbit. These proofs are in effect proofs that we will not be able to find a counterexample, even if there is one.
I don't know why, but it hits me hard. Maybe it's not the best example, since mathematically applicable numbers can be quite big too, but it still disturbs me similarly to how when I first realized that "there's a countable number of definable numbers". I'm still wondering if it's even fair to say that all that "other" stuff (which is the most of math, and as pointed out in this post — can include all sorts of interesting properties that nothing we can "reach" has) even exists. Math is basically made up by humans anyway, it's both a product and a property of how we think. So what it even means for Collatz conjecture to be wrong, if there's there's just one particular counterexample out there we could never find?
Given the very large number of BB(6) programs that exist it’s quite possible that spaghetti ones haven’t really been looked at that much.
Per the author there is only so much spaghetti that’s even possible with less instructions/states.
I have thought about spaghetti code.. spaghetti is..
* Messy. * Disorganized. * Every part of it is connected to every other part.
The third one is the actually really bad one. U tug on one thing and it affects another thing and so on.
I call my code rice code, its like spaghetti code but its made of tiny little modules and no part is connected to another. It also (like spaghetti) has no order / design patterns n stuff. Imo committing to a design pattern is kind of a mini-failure cus your project is now less flexible, you've committed to a certain pattern and everything in future has to follow it. Maybe the next feature does not fit well into this pattern. Ideally you can get to end of project without ever committing to one. (But sometimes u give in and use one to overcome a difficult problem)
For me it is having references that do not make sense (why the noodle is there?), are not obvious by reading the code (can't untangle the noodles) and invisible dependencies (where the two noodles must meet in the spaghetti?).
The invisible dependency is the most evil IMO because it tend to be done by "experts of the code" who assume people should know as much as they do about the structure of the code and it tends to produce huge tribal knowledge and policing.