[ru6xul6]

Hey HN, I'm the creator of Codemap.

Codemap is a codebase visualizer that displays the structure of function calls of any Javascript, Typescript, or Python code. Given a local repo, Codemap statically parses the code and renders a directed graph of all function calls in the least cluttered layout. It helps programmers familiarize with a new codebase, trace possible scenarios that lead to a bug in a function, or understand the scope of impact when making a code change. Codemap runs offline on your local machine and never sends any sensitive code data to remote servers.

I built Codemap because I noticed that good engineers always spend quality time understanding the code architecture before making changes. This process is crucial, and it usually requires drawing a function call diagram on a whiteboard or in the head. Some people use IDE "Find usage of function..." search box for a million times, some people ask senior engineers for tribal knowledge, and some just get lazy and start writing code with ignorance.

As a software engineer, I think there's a better solution than this tedious and error-prone practice. I looked at existing code visualization tools and felt that the visualization tends to be overly cluttered and not that user-friendly. I believed that, with some level of design, I can build a tool that is pleasant to use, easy to navigate, and versatile for any codebase in the supported languages.

During the development of Codemap, I would sometimes grab a popular Github repo to test the Codemap app, and I often find myself exploring its call graph for hours to satisfy my genuine curiosity of "How does <popular project> work?" I'd encourage curious HN readers to visit the website and see screenshots of call graphs from React, Keras, Django, and Typescript (yep the one from Microsoft).

I would love to hear what you love and hate, as well as any questions you may have. I'll be here to respond the best I can (PST time). Thank you :)

[divan]

Hey, great stuff, but my question is whether produced visualization/graph is similar to how would you "see" the code in your head yourself?

The problem of familiarizing/navigating textual codebase is embarrassingly unsolved, and I was exploring this in the post "Rethinking visual programming with Go" [1], but yet my main issue with visualization tools is that they offer intermediate representation of the code, which still has to be "decoded" into proper mental map.

I see the future of these visualizaton approaches in AR/VR. Code visualization should match mental map visualization as much as possible, and the better we can use spatial tools for representation the better the result.

[1] https://divan.dev/posts/visual_programming_go/

[amw-zero]

I think a graph is how we perceive code, I just think the human brain has a very unique way of comprehending graphs. It seems to me like the graph is “indexed” in multiple different ways, so that multiple paths exist between nodes. The brain is also better at categorizing nodes - e.g. “fetch everything that I know about colors in general.”

I definitely think of code in graphs, but it’s definitely beyond just a static graph diagram.

[noir_lord]

Graphs and tags for me, It's hard to describe but I can picture parts of the codebase I've worked with but only roughly until I need to interact with them then I can hold those details in my head but I lose that clarity somewhere else - I think it's a cognitive limit I have, I don't know where that lands against other developers and to an extent I think it can be trained.

As a lead/senior the thing I've observed as the crucial difference between say someone with a year or twos experience vs someone at my point is how fast I can get up to speed with a codebase I've never seen/touched.

Partly I think it's knowing how to use the tools better to get the answers I need and partly pure cyniscism, I've learnt to turn off the "if this was done sensibly" bit in my head so I can actually see what it's doing over what it probably should have actually been doing.

One of the things I really focus on with my juniors is how to use the tools available (and an A4 pad and pen) to figure out what the system is actually doing.

[ru6xul6]

Can't speak for you, but I think a lot of that comes from experience, e.g. put out fires caused by whatever stupid reason, and eventually build up awareness of what could go wrong. Therefore, without reading too much into the code, simply being aware of their existence becomes largely helpful.

[ru6xul6]

Agreed that our brain comprehension goes far beyond just a static graph. Ultimately I want to see all functions as fluid, which can answer dynamic questions like "show me the journey from this input data to that database update query". I think namespace/module/class/method are all valid ways to help organize this mental understanding, but they're also in a rigid form and failed to capture the dynamic nature. I think a 2D graph like Codemap opens up the rigidity a bit, but not entirely yet.

[amw-zero]

The path you describe ("input data to database query") is most certainly representable by a graph. I'm not sure what you mean by "static graph." I do believe our memory is persistent, "static," and finite. We hold discrete pieces of information and connections between them. Aka, a graph.

[ru6xul6]

Hey Ivan, thanks for sharing the great article! I actually read it last year and left a comment (name is Chentai). Back in 2019 I built an IntelliJ plugin [1] as a prototype for Java, and now I'm building Codemap as a natural follow-up. Glad to reconnect :) I definitely share your sentiment towards visual programming. AR/VR may be a better vehicle to convey the code structure, but I think 2D call graph, if done well, could serve as a valuable stepping stone for now. Hopefully Codemap can be the tool that inspires future design and thoughts.

[1] https://plugins.jetbrains.com/plugin/12304-call-graph

[divan]

That's awesome! I remember that project, yes :)

BTW, there is a community for people exploring new ways of coding - https://futureofcoding.org. You might want to join it, if not yet.

[ru6xul6]

Nice, another rabbit hole for the weekend. Thanks for sharing!

[nefitty]

Your caveman-with-a-torch analogy blew my mind.

[ru6xul6]

Totally agreed! I read his article last year and this analogy is still vivid in my head.

[dnt404-1]

I was thinking about a tool as such and wanted to build after I finished my Master's when I would have time (as I work full-time). The experience you described is exactly why I wanted to build such a tool in the first-place. And, this is going to be really useful.

However, is there a Windows version? That is, unfortunately, what I have to use at work.

[ru6xul6]

Sorry for not supporting Windows yet. As I'm less familiar with the Windows toolchain, it takes me a little longer to port to Windows. If you don't mind, please feel free to shoot me an email (in my profile), so I can notify you once it's released.

[ru6xul6]

Hey, the Windows version is ready. Please visit the download page [1] to try it out :)

[1] https://codemap.app/download

[techsin101]

Can you black box framework code. How does it work with react context or redux

[ru6xul6]

Only functions that are defined in your codebase will be rendered in the graph. Thus framework functions are excluded.

[lgregg]

Can this be used inversely to find dead code?

[ru6xul6]

Absolutely. All those individual nodes linked to nothing else are good suspects.

[indentit]

Looks great - how does it work? Or, what is needed to add new language support like C#? Pricing seems very reasonable.

[ru6xul6]

Glad you like it! It uses a language-specific parser to generate function dependencies data, e.g. list of function calls, which are then consumed and visualized by shared UI components that renders the graph. To build language parsers, I started with Language Server Protocol (LSP) [1], but soon realized that some LSP libraries are outdated and I should go deeper to the core language parser, e.g. using Typescript tsserver for JS/TS code. To support a new language, I'll need to integrate a good language parser for that language, generate function dependencies, then the UI and graph rendering will take care of the rest.

[1] https://microsoft.github.io/language-server-protocol/