Two strategies for writing better code

Last week I finished Code Complete, a classic book by Steve McConnell. Published in 1993 and updated in 2004, it’s one of the best platform-agnostic programming books ever written. While all of its 960 pages contain a lot of wisdom, two concepts struck a chord with me.

First, most of your programming time is spent reading code:

Code is read far more times than it’s written. Even during initial development. Favoring a technique that speeds write-time convenience at the expense of read-time convenience is a false economy.

If you ever had to read someone else’s code, you know how it goes. You can’t inherently grasp the meaning of every line and must spend a considerable amount of time deciphering things. The same problems apply to your own code 6 weeks from now.

As most our time is spent reading existing code, it just makes sense to write code that’s as readable as possible. Sure you might know what the variables i, tmp, data2 and state mean at this moment, but months from now you’ll wish you had written recordNum, discriminant, csvLine and tokenFound instead. Similar rules apply to all other programming constructs.

Prefer read-time convenience to write-time convenience. It may take longer now, but it will be better and faster in the long run!

- — -

Second, managing complexity is the single most important technical topic in software development.

Complexity is not a new feature of software development. Computer pioneer Edsger Dijkstra pointed out that computing is the only profession in which a single mind is obliged to span the distance from a bit to a few hundred megabytes, a ratio of 1 to 10⁹, or nine orders of magnitude (Dijkstra 1989).

Dijkstra pointed out that no one’s skull is really big enough to contain a modern computer program (Dijkstra 1972), which means that we as software developers shouldn’t try to cram whole programs into our skulls at once; we should try to organize our programs in such a way that we can safely focus on one part at any one time. You might think of this as mental juggling — the more mental balls your program requires to keep in the air at once, the more likely you’ll drop one of the balls, leading to a design or coding error.

We can only store about five to nine pieces of information in our short term memory. If we need to juggle more concepts when writing or designing software, our performance suffers and we’re prone to make mistakes.

Luckily we can see our code in many levels of abstraction — from the system design view down to the contents of individual routines. If at any level you need to take more than 7 ± 2 objects into account, consider abstracting your code further. You’ll save time and make less errors.

The bottom line is that programmers who compensate for inherent human limitations write code that’s easier for themselves and others to understand and that has fewer errors.

- — -

The book Code Complete 2 goes into a lot of detail on these concepts and on many others. If you’re serious about programming or working as a developer, you owe it to yourself and to your peers to read it now.

Get the kindle edition and read it on the Amazon Cloud Reader in mere moments.

Archived comments from when the blog was self hosted: