New Year Resolution - Read More Code!!!

When was the last time you sat down and thought to yourself, "I'm just going to spend half an hour reading this code"? Your code, someone else's code, it all counts. Given that we're always up against deadlines, and under constant pressure to produce results, why would you do something as apparently pointless as just reading code?

Reading program code is a critical part of what we do as software developers. We don't very often write something completely new. Most of the time, we are changing, fixing, enhancing, or extending something that already exists. If we're going to do that effectively, and without breaking what it already does, then we must understand what it's doing and how and, more importantly, why it's doing it. There are various ways to gain that understanding: you can run the program under a debugger; you can turn on tracing and debugging options if the program offers them; you can build tracing features if they are not already there; specific environments offer their own specific tools, such as a web server's access logs. But the simplest and fastest method is simply reading the code, if you can.

That's where the rub comes. A huge amount of the code that you meet simply cannot be read easily. You end up making heavy use of the navigation and cross-referencing features of your IDE in an increasingly desperate attempt to track the flow of control through layer upon layer of code. Stepping through with a debugger helps, but that has serious limitations: each debugging run represents one execution with one set of data, but you need to understand how the code deals with a whole range of input cases. Gaining this understanding can be a laborious business.

Reading code is something you do every day, because every time you have to debug, change, or extend an existing program, you have to read it first. So why do I say you should spend extra time reading code, on top of what you're already doing? Apart from the fact that more background information about the code you're working with is always worth having, there's another reason. We try all the time to make our programs readable, and actually reading code is the best way to understand how to do that. You need to read other people's code to get a feel for what's readable and what isn't. You need to read your own code to understand how you're living up to your own goals. That means not just reading the code you wrote yesterday, but also the code you wrote last month, and the code that you wrote two years ago. Once you've looked at the code, you can make a judgement on how well you're doing on the readbility front, and resolve to make changes to your own habits accordingly.

Why is readable, understandable code so important? For the very simple reason that if you can't understand it, you can't fix it. If you can't fix it, how can you ever deliver a working piece of software? Things are never right first time. Changing, fixing, and enhancing start almost as soon as you start coding, and they never stop. The way we write code has to be aimed at making those activities as rapid, effective, and enjoyable as possible. Failure to do that leads to broken software, unfixable bugs, missed deadlines, and huge project overruns.

Note: this applies just as strongly in today's agile environments as it ever did. Implementing this week's feature is quite likely to require refactoring and extending code that was written six months ago, or longer. If that code wasn't written with understanding in mind, you'll have big trouble!

So here's my suggestion for a New Year resolution for every programmer. Spend at least a little time each week just reading code, either your own or someone else's, and try to work out what the programmer could have done to make the code more readable. Then put those lessons into practice!