code-reading books

Question

I have been hanging around Borders (the bookstore) lately and have seen some books about "code reading". It covers topics like how to read code and understand it effectively, and how to (if required) refactor it to make reading the code easier.

My questions is this:

Are these books any good for an experienced programmer (2 years+) and do they actually teach you something that you might not have already observed through experience?

I am curious because I have to read a lot of bad (in my opinion) code and would like to make it easier to understand.

Answer 1

I would recommend:

Refactoring:Improving Design Existing Code

working effectively with legacy code

code reading :The Open Source Perspective

Answer 2

This book seems to be highly regarded: http://www.amazon.com/dp/0131177052/?tag=sollc-us-20

I think in order to truly answer your question it would be important to know how much reading of other's code do you do, and are their unit tests with the code, or are you working with legacy code (seems to be defined now as code without unit tests).

There are books that can be helpful in not only reading the code of others, but also to help you write code that is easier to read, depending on what your goal is.

Answer 3

I'll confirm what others have said, Working Effectively with Legacy Code is a supremely awesome book. However, this book isn't so much about reading code as it is an index of safe refactorings for bringing code under test.

I can't help feeling skeptical about some of the "code reading" books I see on amazon.com. While there may be some useful techniques in there, I think that groking code is a skill that improves with practice.

I used to spend a lot of time tracing through the source code of the various free software (open source) applications I use every day, such as Firefox, gnome-panel, nautilus, GNU Emacs, Apache, Mono, GCC, etc. It can be fun and empowering, even if you don't intend on submitting any patches.

As an exercise, I'll often stroll through the bug tracking system of a random open source project, and find an unresolved bug that needs some love, and spend an hour tracking it down. If I find any useful information or the source of the problem, great! If not, oh well, at least I've spent an hour trying to understand a new foreign codebase.

Practice makes perfect.

Answer 4

I have to say that I was quite disappointed by Code Reading: The Open Source Perspective

Not to say that it's a bad book by itself, but for an experienced programmer (I had over 10 years exp at that point), there was nothing new.

There were no strategies for working with large amounts of code, it's more a collection of common idioms and ideas....that I knew already.