471,079 Members | 961 Online
Bytes | Software Development & Data Engineering Community
Post +

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 471,079 software developers and data experts.

Tools to help to understand code written by another person

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
Nov 14 '05 #1
4 1732
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 ... :-(

Nov 14 '05 #2
> 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 ;)
Nov 14 '05 #3
Maybe it has some sense to use this code in the scope of some IDE? For
example Eclipse or KDevelop, SlickEdit... ?

Nov 14 '05 #4
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.
Nov 14 '05 #5

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

43 posts views Thread by grz02 | last post: by
14 posts views Thread by | last post: by
12 posts views Thread by mark2kay | last post: by
232 posts views Thread by robert maas, see http://tinyurl.com/uh3t | last post: by
53 posts views Thread by souporpower | last post: by

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.