Tools to help to understand code written by another person

[Leny]

Hi,

I'd like to colaborate with an open source project that have been in
development for the last four years. There is almost no documentation at
all, and it's extremely hard even to get a global view of what's going on.

Do you know any good tool (maybe a call graph tool, but anything which
helps is ok) for this ?

Any comments would be really welcome.

- Juan

[SnaiL]

1) if code was documented using doxygen style you can use doxygen to
generate api documentation.

2) if project was developed using C++ than you can use Rational Rose
and reverse engineering module.

I do not know more ... :-(

[Leny]

> 1) if code was documented using doxygen style you can use doxygen to

generate api documentation.
Yes.. but the docs are so old and misleading that you are better ignoring
them.
2) if project was developed using C++ than you can use Rational Rose
and reverse engineering module.
Unfortunately it's in C.. Rose would be handy if it had a OOD. I doesn't.
I do not know more ... :-(

Thanks anyway ;)

[SnaiL]

Maybe it has some sense to use this code in the scope of some IDE? For
example Eclipse or KDevelop, SlickEdit... ?

[Michael Mair]

Leny wrote:

Hi,

I'd like to colaborate with an open source project that have been in
development for the last four years. There is almost no documentation at
all, and it's extremely hard even to get a global view of what's going on.

Do you know any good tool (maybe a call graph tool, but anything which
helps is ok) for this ?

Any comments would be really welcome.

If you use an editor which supports ctags, I suggest using them.
A good ctags implementation is exuberant ctags from sourceforge:

http://sourceforge.net/projects/ctags/

Otherwise: Start by writing documentation and give it to the others
to correct. Use doctext or doxygen or whatever rocks your boat and is
easily maintainable. Keep track of changes and have all people agree
on updating the documentation whenever they change something (usually,
if you get them to agree, some still conveniently forget the agreement
or some parts of the documentation). As long as you maintain the
documentation, you will have a very good overview over what is happening
where. No easy method, though.
Cheers
Michael
--
E-Mail: Mine is an /at/ gmx /dot/ de address.