Thursday, 27 March 2008

On readability -- Pure induction in action

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 semantic 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 tot 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.