3 ms·
Whenever I've tried making dependency graphs of programs (usually the easiest type of visualization to create), I find they always turn up some crazy dependenci
by ken 6y ago
Whenever I've tried making dependency graphs of programs (usually the easiest type of visualization to create), I find they always turn up some crazy dependencies you never expected, and don't want. It's easy to hide one weird #include in a list of 20 other #includes. It's hard to hide an arrow going sideways halfway across your diagram.
For visualization types other than dependency graphs or class hierarchies, it's tricky to do any sort of automatic code-to-diagram conversion, so I wouldn't expect there to be a lot of value in that. Even something simple like a state machine might be much simpler to see in diagram form, but it would take quite a bit of sophistication for a visualization program to look at 1000 lines of C and recognize that you're implementing a state machine.
The visual form is more abstract, so you need to start there and have the computer compile it down. Going the other way is always harder. It's 1000 times easier to start with Python code and automatically convert it into machine code, than it is to take machine code and automatically extract a readable Python program from it. That's not because Python is inherently bad for reading or writing. The less abstract form, by its nature, is full of implementation details that don't matter in the more abstract form.