The use of external modules…

…is highly encouraged. Split code into external modules, but not too many otherwise you will reduce your own thought flow as you flick back and to between them. And reducing thought flow leads to reduced code flow. Be logical, be consistent in what you put external to the main core. The core should be as small as possible, but not at the sake of clarity. If a particular piece of code doesn’t get used very often then make it external to the core. If it get’s used a lot, but it’s function is highly abstract or hard to visualise then make it external to the core. Only keep code in the code when it’s necessary, and when it enhances flow by making the core into 1 easy to read and understand module.

Obfuscation vs clarity

There is a time and a place for obfuscation. But unless you’re writing hardware drivers, or embedded systems, and therefore have a need to write your code in the smallest amount of bytes possible, there’s really no need for it. Obfuscation reduces flow. The reader can not adequately grasp the obfuscated code as quickly as clear and concise code. Sure if it’s a quick throw away script, obfuscate to your hearts content if you want to. But if the code is ever going to be maintained by anyone, including yourself then never obfuscate. Flow comes from knowing what the code is doing and being able to see where the code as going. Without flow there is no understanding. And without understanding there is no knowledge. And knowledge will help a lot more in the long run than slightly less bytes being used.

As a side note compilers are extremely good at optimising code these days, significantly better than they were just a few years ago. As optimisation is often given as a reason for writing obfuscated code it’s clearer no longer needed in the majority of cases.

The way of Flow

Good flow is a product of good coding. A program should flow like a river, taking functions from external sources and bringing them together to form the final sea of code. But isn’t the sea too big to view all at once. Yes but even the sea follows a flow that can be easily followed.
Without a consistent flow the coder gets lost, and thereafter the flow loses its way. The flow must be followed constantly. Any deviation leads to chaos and confusion. Think about all the times you’ve looked through someones code and thought, “wow, that’s ugly code, what was the developer smoking when they wrote that”. That is the sign of loss of flow.

Flow doesn’t simply mean other people being able to follow your code. It’s more about the way the code is written. From proper flow comes proper understanding and maintainability of the code. So what is good flow. Unfortunately it’s hard to describe, which will no doubt make you think “Aha, another misguided coder, think’s he knows all but knows nothing”. But good flow really is hard to desribe, it’s like trying to describe a painting by van gogh to a blind person. How do yopu desribe the winderful use of colour, the subtle shades, the shadows, the over all effect of the aubject itself. Coding is an art form, it’s not disciplined like engineering, it’s not as rigirous as a science, it’s controlled by the will of the coder, his understanding of the language and the problem to be solved, and yet the beauty in the code comes from the heart of the gifted coder, transcending thelanguage, the tools, and becoming one with the code. That’s good, pure flow.