The best way to start working on other people's code

Question

I'm looking into adding some features to an open source packages and I would like to know your advices, experiences at "getting into" other people's code.

I obviously already did the following, reading the most relevant part of the code, step debugging, having a good knowledge of the data* processed , generated documentation & graph through doxygen.

*Data, here lies part of the problem with the huge project

I know that there isn't an ultimate way/tricks and working on it for a while is probably the best way to have a good understanding of the code.

But still, I'm sure some of you have some tips to share on that.

Edit: Thanks for the quick and useful replies, especially the ones about Units test, about the book "Code Reading" and the other one pointing to a similar question (shame on me) with also useful comments (i.e. the "code comprehension" keywords for google).

Answer 1

One way that is helpful both for the project as well as to get to know the codebase:

Write unit-tests for the existing code. It gives you a knowledge of which parts of the code do what, and what the boundary cases are.

Answer 2

For me the first thing to have before I change someone other's code is passing unit tests. Once you have unit tests, you can add test for your feature and implement it without the fear of breaking existing code...

Answer 3

I find that the best way to understand someone else's code is to read the unit tests. (This works at a new job or on an open source project.) The tests tell you immediately how the API is designed to be used. If there are no tests you could start out by writing some.

Answer 4

To reiterate what the other have said: read any existing unit tests and write new ones. One other approach that has worked for me when there aren't any tests (unit or otherwise) available is to trace a call from the interface (gui or CL) all the way down the stack and back up again. Do this for a few pieces of functionality that you think are similar to see if they really are then again for different functions. This should give you an idea as to how the system was designed and will quickly highlight any common classes/methods.

Once you've done this, dive in and start writing tests around the areas that made you scratch your head.

Answer 5

A very similar question was asked recently and you might get more info there.

Anyway, have a read of Diomidis Spinellis's excellent book "Code Reading" (link to web site) for lots of info about approaches and tools.

BTW This book won the 2004 Jolt Software Development Productivity Award.

cheers,

Rob

Answer 6

As a supplement to unit-tests try throwing a code documentation tool like JavaDoc, NDoc or Doxygen at the code to generate enheritance diagrams and call graphs.

Answer 7

I find that adding the missing comments is the best way for me to learn their code. Most code I read is missing or short on comments. This way you can force yourself to put in your own words and then months down the road, you are reading your own comments to understand the code.

Answer 8

The problem with other peoples code is that you never really know what shape it's in, and the comments always lie. For C/C++ on Windows, I use a text editor called Source Insight from Source Dynamics; it has the best symbol finding tools I've seen. For Java on most platforms, Intellij from JetBrains.com is similarly impressive. Neither of those are open source, but both of those are actually useful enough to me to pay for. I tend to be a bit evangelical about Source Insight, but everyone that I've ever showed it to for helping get them on board an existing project has found it helpful.

Hope that helps :)

Answer 9

Keep in mind that you don't need to understand all the foreign code in order to fix it or to add features. Often what changes can be localized to a single file, or even a single function. The most important skill is to be able to quickly find that relevant file, class, or function, and for that you can use many approaches, until one of them succeeds. These include plain text searches, tracing, and debugging.