More on Reading Code

Let's revisit reading code and bring in some extra twists. (Hint: Debuggers are WRONG)

First, I know for a fact that I've read a lot of really really awful code. So based on what I said the other day, does this mean that I'm going to write really awful code? I like to think not. I'd like to think that it helps me understand what bad code is, how to read it and how NOT to write it.

Does this help me write great code? Most definitely not. To do that you need to read great code.

But, let's go back to that point about understanding the bad code. I can read bad code pretty well. I've been doing it for years. Sometimes I can actually get into the head of the developer (believe it or not, I used to write some pretty bad stuff, haven't we all?). Anyway, since I can read it well, this is just another reason I don't need to use the debugger.

By actually reading the damn code I can figure out whats going on. A well placed assertion in a unit test can confirm my beliefs. Sure, I could have used a well place break statement, but then I might be tempted to start stepping though code and wasting hours. Well thought out assertions in unit tests not only make the debugger basically useless to me, but give me regression testing going forward.

This would all be for naught if I couldn't read bad code. I read it, I understand it, I don't need the damn debugger to tell me what I already know, I write tests, I improve code.

I'm betting this: people spending hours using the debugger just need to learn how to read code better.