There are a lot of code in open source projects, looking at all of the code is time consuming and can be confusing to a novice like me. Are there any sections of open-source projects that should be focused on?

What should I focus on when I look at code?

I'm asking this in general because if I ask this specifically, the question will only apply in one or two projects rather than an entire group of projects ranging in different types of games and difficulty.


closed as off-topic by Josh Dec 16 '18 at 21:54

This question appears to be off-topic. The users who voted to close gave this specific reason:

  • "Programming questions that aren't specific to game development are off-topic here, but can be asked on Stack Overflow. A good rule of thumb is to ask yourself "would a professional game developer give me a better/different/more specific answer to this question than other programmers?"" – Josh
If this question can be reworded to fit the rules in the help center, please edit the question.

  • \$\begingroup\$ Funny you ask this, I was just looking at the Triple A source code and didn't know where to start... \$\endgroup\$ – Russell Apr 12 '12 at 14:01
  • 1
    \$\begingroup\$ -1 ... you focus on the parts of the code that are relevant to whatever problem you're trying to solve? \$\endgroup\$ – Tetrad Apr 12 '12 at 15:57
  • \$\begingroup\$ Some projects have a section/part of the documentation designed to give new developers an overview over the project. Unfortunably, documentation is often neglected. \$\endgroup\$ – Exilyth May 4 '13 at 10:35

I'd recommend running doxygen: http://www.doxygen.nl/ Here is a list of the features: http://www.doxygen.nl/manual/features.html Doxygen uses the Graphviz tool kit to generate include dependency graphs, collaboration diagrams, call graphs, directory structure graphs, and graphical class hierarchy graphs. I find these types of diagrams helpful when trying to understand a large codebase.

  • \$\begingroup\$ thanks, but in addition, why wont the doxygen work with project folder rather than just working with the sub-folders \$\endgroup\$ – Blue Apr 14 '12 at 18:53

Focus on what you're trying to get from the code. Are you looking for examples of design, for a working sample of how to do a particular thing, or anything specific like that?

Outside of that, have a look at the more general things around the code. Is it readable? Can you follow the program flow? How well commented it is? Do the comments provide useful info in addition to the code, or do they just repeat what is already evident from the code?

Other general factors might include: does the project actually compile as released (a surprising number don't)? What are the dependencies? What is the end-user installation experience like?

You might also find it useful to step through the code in a debugger to get a closer look at what it's doing and how it's doing it.

  • \$\begingroup\$ I'm looking for examples. It's hard for me to look at too much code because I won't understand the code without having to look at it closely. I'm trying to figure out the important parts code in any project. \$\endgroup\$ – Blue Apr 12 '12 at 18:46

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