One of the things that programmers often talk about is the desire to break programs into smaller components, or functions, so that it makes them easier to trace, easier to read, and easier to debug.
But it’s not all that uncommon to see monolithic functions with a lot of code comments to help explain what’s going on in the program.

A monolith ala 2001: A Space Odyssey.
I’m not knocking this, really, because I don’t know the constraints under which a programmer was working. That is:
- What was the budget s/he had when building the program?
- How much time was given to complete the project?
- Were there many people working on the project?
- Was the programmer given time to write the code so they could unit test it, refactor it, or merely make it easier to read?
In short, there’s a lot of reason – I believe – that we can read “bad code,” and it doesn’t always have to be the fault of the programmer (that’s just the most natural thing we have to throw out when we read something we dislike).
Does this mean, though, that we shouldn’t strive to refactor or write code in such a way that makes it easier to understand? Of course not. Assuming we have the time to do so, how might we do it?