One Way to Improve Your Coding

> That "digging" is what I am talking about.

Those are examples I gave are where I don't need to navigate the codebase. The answer is in a single file. So far I manage with the current web interfaces. Locally, I'd use grep and vi. GitHub works ok, but it's hard (but possible) to compare versions or jump between files. Using Google Code or SourceForge I have trouble finding the "Browse" button to even find the code.

There have been times when I've dug into a module when something wasn't behaving properly, and was shocked at how bad the code was. It's not as if I included it intentionally - it's usually a dependency of a dependency of a dependency. All the same, it was garbage that I'd been shipping as part of my application.

Your point still stands, though. Having the code where it's easy to find and read is helpful. And reading bad code can be as helpful as reading good code. Sometimes, the trauma caused by seeing some atrocious code can improve your habits more quickly than reading beautiful code. :)

Here's a counterpoint I find pretty convincing: http://www.gigamonkeys.com/code-reading/

Here's a brief excerpt:

> Seibel: I’m still curious about this split between what people say and what they actually do. Everyone says, “People should read code” but few people seem to actually do it. I’d be surprised if I interviewed a novelist and asked them what the last novel they had read was, and they said, “Oh, I haven’t really read a novel since I was in grad school.” Writers actually read other writers but it doesn’t seem that programmers really do, even though we say we should.

> Abelson: Yeah. You’re right. But remember, a lot of times you crud up a program to make it finally work and do all of the things that you need it to do, so there’s a lot of extraneous stuff around there that isn’t the core idea.

> Seibel: So basically you’re saying that in the end, most code isn’t worth reading?

> Abelson: Or it’s built from an initial plan or some kind of pseudocode. A lot of the code in books, they have some very cleaned-up version that doesn’t do all the stuff it needs to make it work.

>Seibel: I’m thinking of the preface to SICP, where it says, “programs must be written for people to read and only incidentally for machines to execute.” But it seems the reality you just described is that in fact, most programs are written for machines to execute and only incidentally, if at all, for people to read.

> Abelson: Well, I think they start out for people to read, because there’s some idea there. You explain stuff. That’s a little bit of what we have in the book. There are some fairly significant programs in the book, like the compiler. And that’s partly because we think the easiest way to explain what it’s doing is to express that in code.