Anyone who looks at your code must be able to understand at a glance what it is doing, and their “glance” must be correct.

Would you expect a non-musician to be able to work out how a piece of music will sound, from "a glance" at the score?

Or your mother to know the function of a circuit, from a "glance" at a circuit diagram?

Or a butcher where to cut you, from "a glance" at your head x-ray plate?

Hopefully, that's taken care of the "anyone" bit.

Musicians practice endlessly, even when playing a piece they've played hundreds of times before.

Give a circuit diagram to the most qualified electronics engineer, and ask him what it does, and he'll likely want minutes, if not weeks of deliberation and inspection before he'll offer an opinion.

And nobody wants a brain surgeon rushing into their head, after "a glance" at the x-ray.

Beyond the most trivial, computer programs are at least as complicated as all of those. When will programmers stop devaluing their own skills, in the expectation that just anyone should be able to understand the product of hours or days of their effort, "at a glance".

Source code size is not a consideration.

This is another obvious sounding aphorism that simply isn't true. Disk space may be dirt cheap, and computers very fast, but computers don't write or modify code. Human beings do. And human beings have limited resources.

We have limited recall. And limited vision. And one of the effects of that, is that the more spread out the code, the harder it is to grasp an overview of that code. It is this very thing that makes high level languages easier to read, write and maintain than assembler.

The long, narrow source code layout of assembler with one op-code per line, makes it extremely difficult to maintain a knowledge of what variables are "in scope". And nigh impossible to gain and maintain an overview of what the code is doing. High level languages operate by hiding dozens or even hundreds of op-codes behind each individual line. Thereby allowing the programmer to see the wood for the trees.

Laboriously and verbosely spreading out the individual elements of a program's structure in the vain ideal that it will make it easier for the uninitiated novice to understand, is like putting big, grippy handles on a scalpel, in the hope that it will make surgery easier for the local car mechanic.

Programming is hard. It requires learning, skills and practice. It should not be devalued as a blue-collar skill that can be acquired by any walk-in after a 3 day orientation.

It's a well documented fact that the best programmers are anything from 3 to 10 times as productive as the average. But that productivity does not come from them being able to type at 10x the speed. It comes in large part because they do more with each line of code they write.

And that has the knock on effect that during maintenance, there is less code to read. It is easier to form the overview, because each screen-full embodies more of the overall picture. Each line enacts one, complete logical step of the high-level algorithm, rather than that logical step being spread out across 5 or 10 lines.

Yes, each line may require more than "a glance" to understand. But because more logical steps of the full algorithm are visible, the overall flow becomes obvious more quickly.

And your own example makes the point as clearly as any other. If you write your old chestnut as a single line, rather than spreading it out down the page:

PARIS IN THE THE SPRING

The flaw ("bug"), becomes obvious.