How to analyze an open source code without (or with not enough) documentation? [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.

---

Want to improve this question? Update the question so it focuses on one problem only by editing this post.

Closed 7 years ago.

Improve this question

I got an open source code,开发者_开发问答 about 15 mb. I want to understand the main algorithm used there. I started analyzing every part of that code, but I think it will take a lot of time. Are there any approaches to make process easier? I didn't do that before, so it is my first experience.

This one, may be someone knows: https://launchpad.net/cuneiform-linux

---

Use Doxygen. It creates an easily browseable cross-reference of the code base in HTML. And it can also create dependency/class diagrams (if the code is OOP).

The code does not need to have specially formatted comments. Although it does help, Doxygen is smart enough to parse the code and figure stuff out on its own. What I like the most is the ability to click on any function name, variable, class etc. and instantly jump to place where it is declared, defined and show list of all places where it is used. I used Doxygen in the past to chew on some rather large code bases (PHP source code, for example) and it saved me a lot of time.

You can also set up Eclipse CDT and import all source files into a project and get a similar code browser. Although, some stuff like function/class index are not available in that case.

---

Since it's C++ code, you may find Source Navigator useful.

---

As you go, add to the documentation. With any luck there are more people doing the same and between you you will bring the level of documentation up to what is required. That's what open source is all about.

---

Profiling the code will show you which routines are important. Look at both the top and bottom 5% by number of calls.

---

Add a link to the open source project in your question :-)

Maybe others know it or know alternatives.

---

First thing I would do is figure out what are the main entry points. Most programs have a fairly standard format: first, input checking (make sure you got the right number and type of inputs). Second, pre-processing/preparation (opening files, allocating buffers, initializing data structures). Third, they do whatever it is they do, the main processing routine. After that, it's generally output & cleanup. Of course, these may be intermixed (input checking may involve opening the input file), possibly horribly; like a routine fileAccessible(char *fileName) that opens the file, strips the header, instantiates the parser and initializes the lexer by reading the first symbol and putting it into the scanner table. Thankfully, most open-source projects aren't that messed up, but you have to be ready for anything.