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

Sometimes before developing new products we need to understand some existing products or existing source code.

Sometimes to write another small module of that big project we need to understand that big source code.

In our case we need to study and understand a project with lots of files and folders. What is the easiest and most comfortable way to do it ? (especially for C and C++ and under Linux)

  • 2
    Chris F: it would really have helped if you linked to the “exact duplicate” you are referring to. Ugh. Commented Oct 22, 2011 at 3:22

5 Answers 5


All big projects have some sort of documentation usually Doxygen which can help a lot in understanding the code.

You can also use code browsing tools like SourceInsight to study the code.

Last but the best approach is run the code and debug use cases.


Als have already mentioned doxygen which is used for documentation in many projects.
For source browsing: vim along with plugins, cscope & ctags work very well. These can be installed easily on Linux environment and work very well in tandem.
Hope this helps!

  • +1 for vim/cscope/ctags - I would be lost without these when I jump onto big, new projects (although cscope - at least the version I'm using - seems to struggle with some aspects of C++)
    – Radian
    Commented Oct 19, 2011 at 17:58
  • Has anyone ever seen "documentation" from doxygen that is useful? I know it's possible in theory, but I've never seen it in practice - most of the time it's like int foo(int x) - this function calculates a foo from an integer and returns the result where it tells you nothing that the source code itself wouldn't have; and often there's nothing to document the organisation of the project (e.g. what directories contain), how all the pieces fit together, why various approaches were used, etc because the developers made the mistake of thinking "doxygen tautologies" are adequate.
    – Brendan
    Commented Dec 19, 2018 at 18:30

There are different approaches. Documentation if present should help, but in the real world sadly there are quite a few poorly documented code bases. In many cases you can ask some senior developer in the company for guidance, make sure to ask for some high level view of what and how are things done in each module.

You can use a UML analysis tool to extract information from the code base, I suggest BoUML, it is not pretty, but it does a good job at processing C++, and you can create class diagrams by just pulling one class and expanding from there.

An IDE or a similar set of tools that help you navigate through code will also help, as they will allow you to navigate through code much easier than with a plain editor.

While doing the analysis, make sure that you take notes on what you believe each part of the code does, or where you have doubts, then ask a senior in the company to confirm your understandings or to fill in the gaps.


While reading and documentation can be helpful, writing helps too!

Write some tests (nothing serious) which use common features of the codebase, or focus on the components you will need to use.

Try to document some of the things you did not expect, issues you had, and deviations from your team's practices.

You may be surprised by how some programs operate, and how they are expected to be used.


You just need hard work.

Getting familiar with a large codebase is like disentangle a skein. You start somewhere, understand nothing. Then start again elsewhere, still understand nothing.

Start after start, some parts get less obscure. Starting again where you started the first time now provides some clues.

Then the strategy is divide and conquer. Isolate modules and understand them one after the other.

Possible starts are: Makefiles, main() function, file hierarchy, existing documentation (at least a README file) or whatever Doxygen is able to extract even if it was not planned.

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