Reading source code

Question

If you read other people's source code, how do you approach the code? What patterns are you looking for (datatypes, loops, use of control flow, ... )? How long can you read other people's code without getting bored? What is the most exciting patterns that you have discovered so far?

Answer 1

It all depends on what type of code you are reading. Is it a web app, a service, a desktop app? When I do start reading other's code I usually start looking for design patterns used. Or for the framework-specific things. But again this is if you are doing a review. If you are reading for your own interest and to learn something there really is no answer - you should read and understand the code thoroughly.

Answer 2

thanks, if I understand correctly, first step is to identify the context, second identify API's, and place the API's in context. I just realize it is a bit like looking at a building or piece of art, you could focus on the material used, or the function of parts, try different perspectives, judge how parts fit in the whole... there is a nice piece of the process of discovery: here - how mathematicans think

Answer 3

At first, I ignore the urge to change the code. Which is sometimes hard to do. But understanding first and change later saves yourself a lot of nasty "learning experiences."

Next if the format is bad, reformat. Use a code formatter if you have one. This is because you tend to look at the indentation and if that is bad, your understanding of the code is also questionable.

Then, if there are complex datastructures, I like to draw a little diagram. The challenge here is keep it as simple as possible. Large diagrams are fun on the wall, but most of the time, they are to cumbersome to look at. So it is wasted time.

If you finally understand what a piece of code does, write a comment. This is essential, because else you won't understand it the next time you are here.

The following step is to create unit tests. Now you can not only test the code, but you can also test your understanding of the code.

Last, if you understand it al and you know it can (and need to be) better, change it. But be sure to run the tests. Unless you are paid by each solved bug.

Answer 4

A hip new term for this is Code Spelunking.

Answer 5

Pick an item you understand in the final product and see how it is put together. If you've got the unit tests then they are a great help.

Answer 6

Aside from the obvious "work from the top down" general approach, it depends on why I'm reading it: code review, trying to understand a bit of avaialable code to adapt for my own use, trying to learn a new technique, etc.

It also depends heavily on the language. If it is an OOPL, I'll probably do something like this:

1. Look first for the primary class relationships and try to understand the primary responsibility of each class.
2. Look at the interactions between classes to see how they collaborate.
3. Look at the interfaces of the key classes to see what "services" they offer their collaborators.
4. Look inside the non-trivial methods if it's important to understand how they are working instead of what they are responsible for.