Reading / understanding third-party code

Question

When you get a third-party library (c, C ++), open-source (LGPL say), which does not have good documentation, what is best understood so that it can integrate into your application

There are usually a few sample programs in the library, and I end up looking at the code with gdb. Any other suggestions / best practices?

For example, I just selected one of sourceforge.net, but this is just a broad engineering and programming question: http://sourceforge.net/projects/aftp/

Answer 1

I often use several tools to help me with this:

• GNU Global It creates cross-reference databases and can create HTML hyperlinks from source code. Clicking on function calls will lead you to their definitions, and you will see lists of all the links to the function. Works only for C and possibly C ++.
• Doxygen . It creates documentation from Javadoc-style comments. If you tell him to generate documentation for undocumented methods, she will give you a good resume. It can also create hyperlinks to source code lists (and can link to lists provided by htags).

These two tools along with just reading the code in Emacs and doing some searches with recursive grep is how I do most of my original reverse engineering.

Answer 2

One of the best ways to understand this is to try to document it yourself. Gathering and trying to document it yourself, it makes you really dive and test, test and test and make sure that you know what each statement does at what time. Then you can really understand what the previous developer was thinking about (or not thinking in this regard).

Answer 3

Great question. I think this should be considered in full, so I will try to make my answer as thorough as possible.

One thing that I do when approaching large projects, which I either inherited or contributed to, automatically generates their sources, UML diagrams and everything that can facilitate various amounts of ADD is found when studying a new project :)

I believe that someone here already mentioned Doxygen, this is a great tool! You should study it and write a small bash script that will automatically generate sources for the developed application in any tree structure that you installed.

One thing that I haven't mentioned is mentioning: BOUML ! This is fantastic and free! It automatically generates reverse UML diagrams from existing sources and supports many languages. I use this as a way to really capture the big picture of what is happening in terms of architecture and design, before I start reading the code.

If you have money, see the Understand for% language-here% section. This is absolutely great and has helped me in many ways when inheriting legacy code.

EDIT:

Try ack (bestthangrep.com), this is a pretty handy script for finding source trees :)

Answer 4

Check out the heading information. The features you select will be announced there. Then try to determine the actual arguments and pre- / post-conditions of the functions, as this is your main guide (even if they are not documented!). Examples of programs - this is your next bet.

Answer 5

If you have code completion / intellisense, I like to open the library and go "." or "namespace ::" and seeing what happens. I always find this useful, you can navigate through objects / namespaces and see what functionality they have. This, of course, assumes its OOP library with a relatively good naming of functions / objects.

Answer 6

In fact, there is no silver bullet, except just rolling up the sleeves and digging in the code.

Here we earn our money.

Answer 7

Three things

(1) try running test or sample applications, set low debugging levels, and go through the logs. (2) use the source navigator / cscope tool (available on both windows and linux) and review the code to understand the stream. (3) also use gdb in parallel to enter code during application launch for testing / example.