Live data from Hacker News

Ask HN: Why aren't code diagram generating tools more common?

news.ycombinator.com

1–10 of 112 posts

Ask HN: Why aren't code diagram generating tools more common?

#1
When I'm trying to get familiar with a new codebase it often takes me a long time to build a proper mental model of the whole system. Even with my own projects, it's easy to lose track of all the components and their interactions since they're constantly changing, and making hand-drawn diagrams is time consuming.

So my questions are:

- Why isn't diagram generation automated as part of the build process (UML or otherwise)?

- Why aren't code visualization tools more popular? The options out there seem outdated

- Would you want to use these tools? What would be your ideal tool?

Edit: looks like this is a duplicate question https://news.ycombinator.com/item?id=31569646

I can't delete it so feel free to discuss more

Re: Ask HN: Why aren't code diagram generating tools more common?

#3
post #2

I find those diagrams a lot more confusing than just reading and having a mental model of the code.

Seems like someone asked the same question just 3 days ago. Here is the discussion if you're interested: https://news.ycombinator.com/item?id=31569646

Re: Ask HN: Why aren't code diagram generating tools more common?

#7
A decade or so ago, I was tasked with auto-generating documentation, including diagrams (super- and subclasses, to begin with), of a fairly large system in a domain-specific language developed over the past couple of decades. The language had a kind of multiple inheritance (a traitlike system), and at the time around 1500 types/classes/traits/mixins/whatevers, with the entire system all queryable at runtime (and indeed that’s how I generated it—someone else provided Python bindings to the system, then I traversed it all in Python). Just to amuse myself, I generated one class diagram of the entire system. It was around 30 metres wide and I think 30cm high when I zeroed all the margins and padding I could in GraphViz. Flipping its orientation, I got it to be 15 metres tall and almost 1 metre wide. I figured it could be fun physical wallpaper for the office, but in the end settled for just a labelless rendering with random line colours as a desktop background. It was pretty.

But more seriously, it depends on how complex the system is and how it’s modelled. The case I was working with then transferred excellently to such diagrams (shallow and deep inheritance, and other forms of composition and linkage, with every box a link) and key-value property sheets about the types and the likes, but I don’t think I’ve encountered another system where anything even vaguely like that would work particularly well.

Re: Ask HN: Why aren't code diagram generating tools more common?

#8
I have used visualization generation tools but have found them of limited utility to me. When the generator is built into an IDE, the artifact it generates is less useful than the IDE itself, which typically provides a structural (symbol tree) view of the code as well as symbolic navigation ("Go to definition/references").

A visualization can be helpful as an artifact for non-technical colleagues, but I always end up hand-rolling those diagrams to highlight a specific aspect of the system and hide irrelevant features.

Re: Ask HN: Why aren't code diagram generating tools more common?

#9
I’ve felt the same problem. IntelliJ markdown files have support for mermaid is and plant uml diagrams. You have to Google/tick a box to enable it though.

I find creation of a sequence diagram with class instances as columns and method names as arrows can help visualise things.

Re: Ask HN: Why aren't code diagram generating tools more common?

#10
The problem facing these tools is a catch-22 really - diagrams are useful when understanding big messy codebases but big messy codebases are hard to visualise.

For instance, I frequently build small paper diagrams of different code paths through a component and nearly always find leaky abstractions, mixed layers of abstractions, weird cyclical dependencies, etc. etc. and there really is no clear way to diagram this. Instead, you sort of have to make judgements and assumptions to make the diagram concise and understandable; the sort of decisions that machines just aren't that good at.

On the other side, when code is simple and easy to follow then the pay off of building a diagram just isn't there.

Post reply on HN