I was going through this interesting article http://omergertel.com/2010/07/04/how-to-read-code/ on how to read code thanks to a Smashing Magazine link on Twitter. It was an interesting read, although, I felt that it missed out on a couple of important aspects in the code we read now-a-days.
A lot of the code we write these days is built on existing layers of libraries, both server-side and client side. A frequent problem that I have seen programmers reading someone else’s code is that they tend to skip library functions and try to continue reading the code written by one of their colleagues. Now that wouldn’t be a problem except if the programmer does not understand the functionality of the library API being used, the risk of misinterpreting the code or the code remaining vague increases.
Some common examples of libraries being used extensively in our client side code include jQuery and on the server-side, if you are a .NET programmer, there are numerous Dot Net classes.
So, I would definitely recommend that if you are reading code to understand, make sure you understand the syntax, keywords and the API being used of any library within that code.
Other than this, in the old days, about a decade back, we never had such great debugging tools such as we have today for almost any platform. Therefore, we relied more on dry runs. I do not have a scientific reason or a survey to back me up, but I have seen guys who are used to dry runs troubleshoot much faster than guys who are dependent on debugging tools to catch an issue. So I would definitely recommend dry runs where you read code and at every stage visualize the inputs and outputs for each block of code.
So, go ahead, read the article above, but include the two below in your list:
- Dry Runs
- Understand the API of libraries used in the code being reviewed or read for understanding