We' re programmers. Our job (and in many cases our passion) is to make things
happen by writing code. We don't meet our user's requirements with acres of diagrams,
with detailed project schedules, with four-foot-high piles of design documentation. These
are all wishes — expressions of what we'd like to be true. No, we deliver by writing code: code is reality.
So that's what we're taught. Seems reasonable. Our job is to write code, so we need to learn how to
write code. College courses teach us to to write programs. Training courses tell us how to code to new
libraries and APIs. And that's one of the biggest tragedies in the industry.
Because the way to learn to write great code is by reading code. Lots of code. High-quality code,
low-quality code. Code in assembler, code in Haskell. Code written by strangers ten thousand miles away,
and code written by ourselves last week. Because unless we do that, we're continually reinventing what has already been done,
repeating both the successes and mistakes of the past.
I wonder how many great novelists have never read someone else's work, how many great painters never
studied another's brush strokes, how many skilled surgeons never learned by looking over a colleague's shoulder, how
many 767 captains didn't first spend time in the copilot's seat watching how it's really done.
And yet that's what we expect programmers to do. "this week's assignment is to write. ..." We teach developers the rules os syntax and
construction, and then, we expect them to be able to write the software equivalent of a great novel.
The irony is that there's never been a better time to read code. Thanks to the huge contributions
of the open-source community, we now have gigabytes of source code floating around the 'net just waiting
to be read. Choose any language, and you'll be able to find source code. Select a problem domain, and there'll
be source code. Pick a level, from microcode up to high-level business functions, and you'll be able to look at
a wide body of source code.
Code reading is fun. I love to read other's code. I read it to learn tricks and to study traps. Sometimes I
come across small but precious gems. I still remember the pleasure I got when I came across a binary-to-octal
conversion routine in PDP-11 assemble that managed to output the six octal digits in a tight loop with no loop counter.
I sometimes read code for the narrative, like a book you'd pick up at an airport before a long flight. I
expect to be entertained by clever plotting and unexpected symmetries. Jame Clark's gpic program (part of his
GNU groff package) is a wonderful example of this kind of code. It implements something that's apparently very
complex (a declarative, device-independent picture-drawing language) in a compact and elegant structure. I came away
feeling inspired to try to structure my own code as tidily.
Sometimes I read code more critically. This is slower going. While I'm reading, I'm asking myself questions such
as "Why is this written this way?" or "What in the author's background would lead her to this choice?" Often I'm in
this mode because I'm reviewing code for problems. I'm looking for patterns and clues that might give me pointers. If
I see that the author failed to take a lock on a shared data structure in one part of the code, I might suspect that
the same might hold elsewhere and then wonder if that mistake could account for the problem I'm seeing. I also use the
incongruities I find as a double check on my understanding; often I find what I think is a problem, but it on closer
examination it turns out to be perfectly good code. Thus I learn something.
In fact, code reading is one of the most effective ways to eliminate problems in programs. Robert Glass, one of
this book's reviewers, says, "by using (code) inspections properly, more than 90 percent of the errors can be
removed from a software product before its first test.
In the same article he cites research that shows "Code-focused
inspectors were finding 90 percent more errors than process-focused inspectors." Interestingly, while reading the code
snippets quoted in this book I came across a couple of bugs and a couple of dubious coding practices. These are problems
in code that's running at tens of thousands of sites worldwide. None were critical in nature, but the exercise shows that
there's always room to improve the code we write. Code-reading skills clearly have a great practical benefit, something you
already know if you've ever been in a code review with folks who clearly don't know how to read code.
And then there's maintenance, the ugly cousin of software development. There are no accurate statistics, but most
researchers agree that more than half of the time we spend on software is used looking at existing code: adding new
functionality, fixing bugs, integrating it into new environments, and so on. code-reading skills are crucial. There's
a bug in a 100,000-line program, and you've got an hour to find it. How do you start? How do you know what you're looking
at? And how can you assess the impact of a change you're thinking of making?
For all these reasons, and many more, I like this book. At its heart it is pragmatic. Rather than taking an abstract,
academic approach, it instead focuses on the code itself. It analyzes hundreds of code fragments, pointing out tricks,
traps and (as importantly) idioms. It talks about code in its environment and discusses how that environment affects the
code. It highlights the important tools of the code reader's trade, from common tools such as grep and find to the more
exotic. And it stresses the importance of tool building: write code to help you read code. And, being pragmatic, it comes
with all the code it discusses, conveniently cross-referenced on a CD-ROM.
This book should be included in every programming course and should be on every developer's bookshelf.
If as a community we pay more attention to the art of code reading we'll save ourselves both time and pain.
We'll save our industry money. And we'll have more fun while we're doing it.
Dave Thomas
The Pragmatic Programmers, LLC http://www.pragmaticprogrammer.comBook homepage | Author homepage
(C) Copyright 1995-2003 D. Spinellis.
May be freely uploaded by WWW viewers and similar programs.
All other rights reserved.
Last modified: 2003.05.12
Foreword by Dave Thomas
