Entropy of the code
Most often when you develop software that grows big over time, it is normal to come back and rewrite parts of it. This may happen because you found a major flaw in the logic. But as you keep coming back to fix things in the code written a while ago, the context in which you coded has to be established again and again.
You end up reading your code going through the myriads of nested loops and conditions and added to that will be the complexity of the data structures that lives through those conditions and loops. Even after a week, it becomes hard to understand why you put those conditions. Over time, when you test and fix bugs, the conditional statements, the nestedness, the blocks within those conditions and loops, the data structures grow dangerously complex.
Now when you read them, they overwhelm you. If this is happening to you, it just points to one simple thing. The entropy. Like a bachelors room that grows messier over time, the entropy of the code also increases over time. It so happens that some parts of the code are visited very often as they do the most critical job. They keep getting hammered as you learn new problems or find newer scenarios that did not exist when you first coded them. The parts where entropy is highest needs a distribution or a re-organization to decrease the effect of entropy. This has to be a constant activity as soon as you realize the higher entropy zones in your code and normalize them. Ensuring that no part of your code peaks in entropy can be a measure of accessibility or readability of the code. This enables quicker turnaround on fixes.
As a broad guideline, if a function has many nested loops and conditions, and each one of them does some specific check and action, distributing the action blocks outside of this function into their own functions and maintaining only the top level skeleton of the checks that show the high level flow of the algorithm can reduce the entropy. This can be repeated into those child functions as well as they grow. Similar strategy of distributing big chunks of loops that does something into its own function and can be called from the main function with a meaningful comment.
The code distribution is akin to a hyper-linked text. You always should be able to get the main context without getting digressed into sub-contexts by hyper linking those sub contexts. This way it is possible to quickly trace a specific path through the hyper-linked text. Similar approach for coding can help it accessible and readable.
Often this aspect of coding is overlooked in projects due to deadlines. In other cases, the programmer is not aware of this. Keeping the code in a hyper-linked way can help discuss any problem directly with the code without the need to write design documents or even be able to adjust the code as a solution is being discussed or evolved to see its effect. This is entirely possible if the programmer spends that extra time to address entropy and distribution.
