Re: Exploring a code base?

[Stefan Monnier]

> When the change I’m doing is not very invasive, the affected subgraph
> fits completely in my head. However, when it doesn’t, I find myself
> having to record my traversal state. I create an Org buffer and
> manually maintain a queue of nodes, marking those I haven’t yet
> visited with TODO and those I have with DONE. Then I pick the first
> TODO, grep or xref-find-references on it, add any relevant nodes to
> the queue, make the necessary changes in the code, and mark the node
> DONE. Repeat until no TODO.
>
> This is rather tedious. It feels like there should exist a better way,
> maybe with a visualization of the graph structure.

That's a good question.  I have resorted to writing down (in some
arbitrary text file) the things that are still pending, like you
describe (even in case it fits in your head, writing it down can be
needed if you're interrupted in the middle), and indeed it's
not satisfactory.

In other cases, I try to make use of the compiler's checks to keep track
of what I still need to do.  Typically by renaming the functions/types
I still need to investigate so the compiler points me to the places that
still need to be changed (sometimes, this renaming is not really wanted
and is hence temporary, so I use a "funny" name which I can easily fix
later with a simple search&replace).

Obviously, this only works if you can rely on something like a compiler
to catch the problems.

I'd be interested to hear if someone has a good solution for that.
Maybe some way to "push" a particular file/location on a stack of
pending issues (along with some brief description, maybe) and then some
way to display it in a reasonable way...


        Stefan