[outsomnia]

Can you absorb or re-absorb what it is doing rapidly by looking it over for a few seconds?

If not, there's something wrong... if you can't divine the author's intention at a glance, you and anyone else looking at it will find it hard to spot bugs that deviate from that intention.

[rgoulter]

This kinda reminds me of Steve Yegge's writings about different kinds of programmers.

His main taxonomy is that there are programmers who prefer mistakes are caught as soon as possible, vs programmers who don't mind fixing things as mistakes are found.

Similarly, he says one extreme style is "I have full understanding of the domain and my code, I want as much code on the screen at once" ("expert") as opposite to "I want as much context/documentation, to make the code on screen as understandable as possible" ("newbie").

There's an ambiguity in the standard of "how rapidly can the code be understood?". By who? With what familiarity with the codebase, and with the domain?

[AnimalMuppet]

By who? By those who are working on it (now and in the future).

Let's start with the author. If the author can't understand it in six months, that's bad.

Then, the author's co-workers, now and in the future. The author may be a genius who never forgets anything, but will his successor be as good? If the successor can't understand it, that's bad code.

[JZN666]

> Can you absorb or re-absorb what it is doing rapidly by looking it over for a few seconds?

No. Not only because code is essentially poorly structured, but also because I'm not fluent in subject behind a code. Example is operating systems: when I look in Linux's source code for example, I can't understand which problem is solved by each routine. But does that make Linux source code "poor structured"?

[outsomnia]

You are too inexperienced to work on the code or understand its context, even if the code is perfect?

Then you are the problem detected by your being unable to absorb what it is doing.