Reading Programs
I have recently purchased the Silver Anniversary Edition of Gerald Weinberg's
classic book, The Psychology of Computer Programming. I remember
borrowing the original edition from the University of Toronto library and
devouring it, intrigued by the human side of programming. Surely this
foreshadowed my interest in Agile Software Development and Extreme Programming.
The first section of the meat of the book is entitled Reading Programs,
including Gerald's observation that the advent of the terminal reduced the
amount of time programs spent reading one another's work. When build cycle times
were long, programmers couldn't afford a broken build, so they had to be more
careful. This results in reading their own work more often. Also, while waiting
for a build cycle to complete, programmers would wile away the time reading one
another's programs. Gerald's point is that programmers are missing something by
not reading programs, much the way that a novelist can only develop her craft so
far without reading novels herself. I think it's clear that reading each other's
work is important if we want to improve our own work.
So do we read programs now more than we did in 1971? I can point to an
increase in the number of programming books that include sample code, but many
of those books are technical tutorials on how to use SQL, or PHP or Windows
Forms. These books teach us to program, but don't necessarily teach us to
program well, although they might just teach us how not to program
well.
It is my personal pet peeve: most code examples I see in books suck. They
feature poor indentation, abbreviated variable names, long methods, hardcoded
dependencies and, worst of all, some of them are so abstract as to be useless.
When I sat down to write JUnit Recipes, one of my mandates was to have
meaningful, professional-looking code samples. I wanted the samples to be of the
same quality that I might ship to a client. If my book is one of the few times
that my readers will read someone else's code, I at least want to set a good
example.
Pair Programming is another technique I use -- although rarely these days --
to read other people's code. Slowly I am improving at letting the other person
drive, and that's giving me opportunities to read code and learn in the process.
I have made a number of stylistic changes in my personal coding standards in
response to navigating while someone else drives. It has improved the quality of
the code I write. I only wish I were doing more of it.
So how much code have you read in the past week? The past month? the
past year? What could you do to read more?
jbrains on 11.08.04 @ 06:53 PM ET [
link]
