6

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..

Billy ONeal
  • 104,103
  • 58
  • 317
  • 552
slayerIQ
  • 1,488
  • 2
  • 13
  • 25
  • Whatever you end up doing, it's good to keep a log of your notes (build command lines you ran, functions you traced, ideas you had, etc.) Not only will it help you if you forget, but you could also contribute them to the project's wiki or make a post on your own blog about your findings. – HostileFork says dont trust SE Jan 06 '10 at 20:52

4 Answers4

2

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.

Valentin Golev
  • 9,965
  • 10
  • 60
  • 84
1

  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.

Eric Petroelje
  • 59,820
  • 9
  • 127
  • 177
1

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.

Jonathan Feinberg
  • 44,698
  • 7
  • 80
  • 103
0

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.

Amber
  • 507,862
  • 82
  • 626
  • 550