Re: How do you read source for big programs?
From: Chris Croughton (chris_at_keristor.net)
Date: 11/30/04
- Next message: Charlie Gordon: "Re: OT: Unix C programming for finding file"
- Previous message: Chris Croughton: "Re: fseek past the eof"
- In reply to: kj: "How do you read source for big programs?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Tue, 30 Nov 2004 10:21:58 +0000
On Mon, 29 Nov 2004 13:02:00 +0000 (UTC), kj
<socyl@987jk.com.invalid> wrote:
> I consider myself quite proficient in C and a few other programming
> languages, but I have never succeeded in understanding a largish
> program (such as zsh or ncurses) at the source level. Basically,
> I quickly become disoriented, losing sight of the forest for the
> trees.
This is usual. You should try a really large program like GCC if you
really want to be confused.
> What's your approach for understanding a large program at the source
> level? By "understanding a program" I mean more than just figuring
> out where to zero in to make a small change (e.g. change the value
> of a global variable), but rather to digest as much of the source
> as necessary to know the program's structure in detail, know where
> in the source to go for any customization you'd want to make, know
> what you'd need to do to port the program to a different OS from
> the one it was written for, know what you'd need to do to abstract
> some of the program's functionality into a smaller subprogram that
> you could embed in a program of your own, etc. Bottom line: the
> goal is to know the program's source inside out.
Read the documentation, especially the design documentation. If there
is any, of course. Otherwise, you need to write the design
documentation from studying the code (not necessarily to production
standard, but effectively you need to do what the authors should have
done originally).
In particular you need to draw call trees (or equivalent tables), module
connectivity and data flow diagrams, and the like. Possibly also state
diagrams or tables.
With ncurses there is a lot of documentation, and it's a library so a
lot of the functions are pretty standalone or call more basic functions,
so it's not too bad. From what I remember zsh has little internal
documentation and the parts are more ineter-related so it's worse.
> I realize that this is a task that could take days, if not weeks.
Months. Years.
> I'm willing to put in the effort, but I'm really at a loss as to
> how to proceed. (My current interest is reading the source for
> zsh, but some day I'd like to read the source codes for Perl, Emacs,
> Firefox, Apache, you name it.)
Good luck (you'll need it)!
There are tools which can help. Check out doxygen, for instance,
available for Windows as well as *ix, it can draw up call and data trees
(although it's better at C++ than at pure C) and can (with a little help
sometimes) extract code comments as documentation. There are other
cross-referencing programs which can sometimes help.
Chris C
- Next message: Charlie Gordon: "Re: OT: Unix C programming for finding file"
- Previous message: Chris Croughton: "Re: fseek past the eof"
- In reply to: kj: "How do you read source for big programs?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
|
