Radical engineering principle: on readability
Memento:
Engineering principles are true by good convention.
Principle:
Optimal "readability" is readable _optimality_.
Comment:
Never ever optimize. <*>
Do make code readable. <**>
Clean up the dark side. <***>
Readability before all. <****>
The only way to optimal code. <>
Extended:
<*> Includes refactoring, the semantic side of optimization.
<**> Includes restructuring, the syntactic side of readability.
<***> Includes comments, the dark side of readability.
<****> Includes the dark side of optimality.
<> Readability dis-including itself.
Hint:
Optimization of a sub-optimal program (algorithm, system, product, procedure, argument) is a pointless hack that leads to solutions at local minima. Improvement of such local-minimal solutions is impractical, given that the underlying landscape is so redundancy-reduced as to result completely chaotic.
In practice, if a sub-optimal program gets optimized (once upon a time there was the blessed post-optimization-upon-need, nowadays we have optimization as an integral programming practice called refactoring and its cousin performance), any required improvement needs stepping back a number of iterations until another approach, more basic but broader enough for the extended problem, gets in sight. The more premature the optimizations, the more paralyzing the sub-optimized local-minimal results. And the iteration starts over...
To break the deadly cycle, just stop optimizing in any form, start instead striving for readability. To get a basic idea of readability, we can think of the optimal target as a program code that can be _read as easily_ by a professional in the field as something in between a technical article and a page of mathematics. That is, code must speak for itself!
[A side note to the casual reader: please don't get too strict on terminology, I'm using all terms in their _broader_ sense, so that, for instance, should you be a software engineer, where I say "coding", I actually mean any act of production, including all that there is from analysis to delivery. The same holds for other disciplines. The only restriction is maybe in that I try to stay within the bounds of "engineerings" and "applied sciences", although, sooner than later, we'll catch up with "social sciences"...]
That said, apart from avoiding the inconveniences of optimization (taken in its broadest and weakest sense), readability brings its own distinct advantage, indeed an exclusive property: readability and only readability leads to optimal programs. We still miss a formal proof, but this might be apparent if we think what an _optimal_ program is: on a side, readable entails manageable so much as the latter requires the first; on the other side, every _ideal_ relates to needs that, in any ultimate sense, are "human" and only "human". Indeed, "who" needs _what_?
[For example, say one is programming and keeps readability in mind.
That means:
1) writing code with readability in mind (rather than "writability");
2) designing a system under permanent (re)structuring, down from its very (im)permanent foundations;
3) keeping the whole environment always clean and tidy, as if important guests are to arrive at any moment soon (and that includes documentation; yes, please, if in doubt, just DROP IT ALL!!).
That leaves plenty of room for movement, and the code stays always around the optimal balance between minimality and continuous improvement.]
We can't predict the future, we make it: we are pure induction in action.
