A Formal Theory of Spaghetti Code

Besides Spaghetti Code there is a development practice which is relatively common and yet people usually fall for it. I like to call it: flag oriented programming.<p>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.<p>I once tried to convince a friend not to use it. In a part of the code, I asked him: &quot;Look, how can you guarantee that the states of the flags are consistent here?&quot;, 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 &quot;set methods&quot; for each of the flags, each method called a function &quot;checkFlags&quot; which detected inconsistencies in the flags and automatically set them to a consistent state.<p>I continued: &quot;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.&quot;<p>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.

Theory-curious but mostly workaday programmer here. Does this have any application to detecting spaghetti code in conventional codebases, or is it specific to the Busy Beaver problem?<p>“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.

A related concept to spaghetti code is what I like to call &quot;Jenga code&quot;. I.e. code that looks like it started ok, but people kept modifying it without proper support or thought for the modifications, and has now reached a point where the tiniest change will cause the whole thing to collapse.

It’s a fun crack at the problem. I’ll say (very annoyingly) that I have a hunch that the formalization is fundamentally wrong somehow that I can’t quite put my finger on, even though branch factor does seem like a really great candidate for the relevant measure.

This is not the first time I see posts from this blog on this topic here, and I feel like I&#x27;m not qualified to read that, since what I&#x27;ve read in these posts is basically all I know about it anyway, and I don&#x27;t know why should I even be interested in it — I mean, it&#x27;s pretty useless, isn&#x27;t it… But almost every time there&#x27;s something deeply disconcerting in them.<p>&gt; 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.<p>I don&#x27;t know why, but it hits me hard. Maybe it&#x27;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 &quot;there&#x27;s a countable number of definable numbers&quot;. I&#x27;m still wondering if it&#x27;s even fair to say that all that &quot;other&quot; 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 &quot;reach&quot; has) even exists. Math is basically made up by humans anyway, it&#x27;s both a product and a property of how we think. So what it even means for Collatz conjecture to be wrong, if there&#x27;s there&#x27;s just one particular counterexample out there we could never find?

The article presents an interesting definition for spaghettI. However by using the current known best in each BB class doesn’t really offer a robust analysis in each class. I think it would be pretty interesting to see how much spaghetti it’s possible to make with a 6 states and then examine some of those BB machines vs reducible ones.<p>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.<p>Per the author there is only so much spaghetti that’s even possible with less instructions&#x2F;states.

[Discussing article title, not article]<p>I have thought about spaghetti code.. spaghetti is..<p>* Messy. * Disorganized. * Every part of it is connected to every other part.<p>The third one is the actually really bad one. U tug on one thing and it affects another thing and so on.<p>I call my code rice code, its like spaghetti code but its made of <i>tiny</i> little modules and no part is connected to another. It also (like spaghetti) has no order &#x2F; design patterns n stuff. Imo committing to a design pattern is kind of a mini-failure cus your project is now less flexible, you&#x27;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)

IMO Spaghetti code is not having references pointing to and from everywhere.<p>For me it is having references that do not make sense (why the noodle is there?), are not obvious by reading the code (can&#x27;t untangle the noodles) and invisible dependencies (where the two noodles must meet in the spaghetti?).<p>The invisible dependency is the most evil IMO because it tend to be done by &quot;experts of the code&quot; 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.

Ah the complexity boundary! Any socially constructed artifact will tend to the most complicated thing its society can reasonably support.

seems the author should be aware of the Big Ball Of Mud <a href="http:&#x2F;&#x2F;laputan.org&#x2F;mud&#x2F;" rel="nofollow">http:&#x2F;&#x2F;laputan.org&#x2F;mud&#x2F;</a>

&quot;quasihalts in &gt; 10^502 steps&quot; ahh yes, my best attempts at javascript

Theorem: Any spaghetti code that&#x27;s pushed to production and solves a customer&#x27;s problem is no longer spaghetti code. #deployordie