Diasparsoft Logo Let's write software that people understand.

Home | Contact

Training

JUnit support

Outsourcing

The work that Diasparsoft did for us was outstanding. We are now using the software on a daily basis and their work could well have a dramatic impact on the Reds' organization in the near future.Cincinnati Reds Baseball Club.


Publications

Tips & Tricks

Diasparsoft Toolkit

What is Diaspar?

Interesting Bits RSS

Home » Archives » November 2004 » Reading Programs

[Previous entry: "HELP: I need a page translated from Japanese"] [Next entry: "Software Licensing has changed"]

11/08/2004: "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?