Making yourself familiar with projects

Question

Today i did a checkout of some open-source projects just out of curiosity. So after a while i was looking at the code of OTTD (http://www.openttd.org/), i just didn't know where to start looking or how to understand the project. I know you cant get familiar with such big projects in one or two days, but how do you guys handle such things where do you begin what do you look for etcetera etcetera..

Answer 1

Docs for the source of OpenTTD: http://docs.openttd.org/ , they will be helpful.

Also, dev wiki: http://wiki.openttd.org/Development .

How to get familiar?

First, try compiling. Compile it to your platform and make sure it's running correctly.

Then, pick up a bug or something from to-do list and try to implement it, or just play the game and think about adding/changing something simple. Of course you can fail and want to change your task, but every try will be a step into understanding a structure of a project.

---

For me, the compiling part is most annoying part. I think it's because I'm on Windows :-) I've hardly ever managed to compile something from scratch without days of thinking and spamming people etc. But I quickly get used to many projects which aren't needed to be compiled, such as written in PHP or Python or JavaScript.

I just did something with the code. Changed some important constants :-) Writing plugins. Whatever. And one day I understood that now, If I choose almost any task from issue tracker, I'll be able to find out at least where the problem located.

If you're just reading code, you aren't gonna know it well! Even (good) fiction books can't be understood fully only by reading them again and again.

Answer 2

A lot of times it helps to have a lot of scratch paper, or some form of rapid diagramming tool - as you come across things, sketch out how they relate to each other. Over time you'll get a sense of how things are laid out and what interacts with what, sort of like an ad-hoc class diagram (but much more freeform).

Pick a starting point that is somewhere you can identify: maybe this is the user input processing, maybe it's the initialization sequence for the program - and trace the flow of execution from there to get an idea of how things happen.

Hopefully, the source code had helpful comments - maybe even, in OpenTTD's case, doxygen-style comments, so you can get a nice set of docs for it.

Answer 3

1. Download the code.

2. Set it up in your favorite IDE so that it builds and runs.

3. Set a breakpoint at the beginning of main()

4. Spend some quality time stepping through in the debugger :)

Gives you a good feel for how things are put together, where the dependencies are, and what happens when you do things in the app.

Answer 4

Another good strategy is to start from some piece of software that you use, even one you rely on. Then find the most annoying bug, and fix it.