Re: Exploring a code base?

["Daniel Martín" <mardani29@yahoo.es>]

Yuri Khan <yuri.v.khan@gmail.com> writes:
>
> 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.
>
> What do you use to explore and map a code base and perform extensive
> changes on it?

It depends on the programming language, but I usually rely on a compiler
to generate an index for my project in the background.  An index is
similar to a TAGS file, except that it was generated by an actual
compiler and therefore all code relationships (child of, parent of,
referenced by, aggregate of, etc.) are stored in the index and are
usually very accurate.

There are many tools that can "visualize" code indexes.  For C/C++
languages, there is Sourcetrail
(https://github.com/CoatiSoftware/Sourcetrail), for example.  Clangd
(https://clangd.llvm.org), a language server for the C family of
languages, can also generate an index that you can use to perform simple
refactorings, like a rename, or to ask for the call graph of some
function.  Clangd is usable from Emacs via Eglot or lsp-mode.

This code index approach still has limitations, though, like how to make
sure that the index is completely up to date before a query, or how to
scale it to codebases of millions of lines of code, where creating an
index in a single machine is usually not possible.  But I think a
compiler-generated index may be a good trade-off over using grep +
keeping track of things manually.