Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

Possible Duplicate:
How do you dive into large code bases?

I want to study the source code of a large project (for example, the Doom 3 source code) and I would like some help determining how I should navigate the code. How should I start reading it? Should I find a main() function and go on from there? Do you have any other tips that may help me?

share|improve this question

marked as duplicate by Walter, delnan, GlenH7, Martijn Pieters, Caleb Jan 16 '13 at 17:04

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

Have a look at: programmers.stackexchange.com/q/115040/53019 and: programmers.stackexchange.com/q/118419/53019. After you have read those over, please revise your question so that the community can provide a better answer. –  GlenH7 Jan 16 '13 at 16:48
Just download the code and start looking at it? –  Ramhound Jan 16 '13 at 20:05

3 Answers 3

Find something you want to change and use that as a way to start finding your way into the code base. So try and add a new weapon type for example.

share|improve this answer

Be focused. What do you want to learn? Do you want to learn how it renders a room? Do you want to know how the AI works? Do you want to know how it does sound? How about how the files are organized? Or what exactly is in main()?

Pick a topic and dig in. Don't just aimlessly poke around in the files. Give yourself a simple question, then try to answer it.

share|improve this answer

Yes -- two main pieces of advice when looking at codebase which is brand new to you, and trying to figure out "how stuff works" (as opposed to looking to solve a specific problem):

  • It's perfectly reasonable to start with main() and work your way down. Ideally, you'll find that the program is a sequence of relatively few operations, such as (hypothetically):

    1. set up graphics contexts
    2. set up IO
    3. set up datastructures representing the world
    4. loop on events

    For now, act as if these high-level calls are part of the language -- assume each works as needed, and treat each as a black box, until you have an idea how the whole program (relatively simple at this level) fits together.

    Once this is clear, pick one high-level operation you're interested in, find the function that implements it... and go back to step one, figuring out how that function works in terms of the simple operations it uses. Lather, rinse, and recur until you have a better grasp on the program as a whole; for any given branch of this exploration, you can stop at the point where you feel you understand enough "for now" (such as when the operation a function calls is provided by another library), and move on.

  • Tools, tools, tools -- one thing which will make the above process a lot easier is a set of tools to help you answer questions like

    • where is function foo() declared? defined?
    • what are all the places that function bar() is called?

    On Unix, tools like gnu idtools, global, or the tags support in emacs or vim can help you here. Most IDEs, such as XCode, Eclipse, or Visual Studio, also have tools to answer these kinds of questions.

But most of all, remember that in many ways a big program is like a small program, just... bigger (and with tricks and techniques to manage this size). The language works the way you already know, and in a well-designed program, the code to do any one thing will be relatively small (even if it depends on a operations defined elsewhere to stay manageable in size).

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.