5 ms·
The symbolic lookups and diagrams described are already implemented in modern IDEs. People who rely on relatively simple text editors and text / regex search ma
by barrkel 10y ago
The symbolic lookups and diagrams described are already implemented in modern IDEs. People who rely on relatively simple text editors and text / regex search may be less aware of this, of course.
I do agree that visualizations are lacking. In part this is because of difficulties in complete analysis, and rather than do half a job, they don't do any job at all. And in other parts its because different tools do a better job: for example, instrumenting profilers are better at showing control flow.
I generally want three kinds of things in my head when reading code: control flow, data flow and data shape.
But there are different resolutions to this. Control flow may be simple, at the method level; or it may be more complex, with asynchronous callbacks, queuing systems, RPC, web service requests and orchestrations controlled by configuration.
Data flow may be simply knowing where in the code a particular attribute is updated and where it is read and used to make a decision. But it's also about where the data came from ultimately - what all the ingredients are that go into its formation - and also what other data it in turn affects.
Data shape has to do with the simple shapes of structures, but diagrams are scarcely needed for that - a glance at the definition of the structure is enough to commit it to short-term memory. More interesting is global invariants, local invariants, longer chains (how you get to one distant structure from another via links), the database model, configuration data model, static data vs dynamic data.
Most of the interesting information is at a higher level than can reasonably be analyzed in most Turing-complete languages. The best info comes from profiling or debugging.
- alexc05 10y agoCan visual studio do the graphical representation of a C# codebase? A javascript file? Looking at Coati.io it can't do those languages yet, but the graphical flow chart looks really amazing to me and I'de love to try it out on my own code.
- barrkel 10y agoClass descriptions are not only put into diagrams, they're interactive controls. Ten years ago, the model-driven development trends focused on making more and more of the code driveable by UI representations and code. People tried to model code using UML or UML-like representations, with two-way links. Tooling inferred models from existing code. For more current approaches, see "Code Maps" in the VS 2015 release notes here - https://www.visualstudio.com/en-us/news/releasenotes/vs2015-rtm-vs https://www.visualstudio.com/en-us/news/releasenotes/vs2015-... Doing proper control flow is done less often for the reasons I explained. Profilers do it better. See e.g. the Call Graph in AQTime: https://support.smartbear.com/viewarticle/43205/ https://support.smartbear.com/viewarticle/43205/ - it lets you drill through the callers and callees of each function as seen in practice. This means it can see through polymorphism, reflection, dynamic loading, function pointers - all the things that make static analysis infeasible.
- xorblurb 10y ago(Note: VS Entreprise is $6000 away. I see a market for cheaper code visualisation tools...)
- stonemetal 10y agoVisual Studio does, but only in the "Enterprise" configuration($6K per seat). I haven't used it to be able to speak to its quality.
- 72deluxe 10y agoWell you have the class view which tells you a lot. And you have the object browser which is very useful too. It's not quite the same but I think it tells you a lot about a class without having to do masses of reading.
- bobajeff 10y agoIn the past working on a large c++ codebase I've tried using a debugger to get an understanding on how a function gets called. Even the debugger fails when you come across indirect calls. Also in gdb multiple threads make it easy to miss something when stepping through code.
- realharo 10y agoVisual Studio's debugger has some really nice features and interface for dealing with multi-threaded code https://channel9.msdn.com/Shows/Visual-Studio-Toolbox/C-Plus-Plus-Debugging-Tips-and-Tricks#time=19m42s https://channel9.msdn.com/Shows/Visual-Studio-Toolbox/C-Plus...
- barrkel 10y agoDebuggers aren't always the best tool for figuring out control flow - accidentally step over something and you can miss it - but they are useful to explore the map of data in memory. Some debuggers let you expand out the map hierarchically, others use separate windows (e.g. the old Borland IDE Debug Inspector windows). For exploring control flow, an instrumenting profiler is really useful, if you can easily isolate a representative code run.
- bigger_cheese 10y agoA few years ago now at my work I wanted to get my head around how our large c++ code base worked I used a tool called Doxygen it was pretty useful for reading and visualizing the source code. It output html pages and could generate dependency graphs etc automatically would show you which file a function came from let you browse by class or by individual source files etc. You could easily see every file a class was referenced in etc. Downside was it took a long time (many hours) to scan the entire codebase.
- Asooka 10y agoI would strongly suggest you check out rr - Mozilla's Record and Replay framework https://github.com/mozilla/rr https://github.com/mozilla/rr . Don't let the name confuse you - it's not specific at all to Firefox. It can record a process's execution and replay it in gdb, and lets you step and continue backwards. This last point is super powerful - let's say you see that some variable has an unexpected value. You can set a watchpoint on it, then reverse-continue and gdb will stop at the point it was changed. It has been invaluable in finding some tricky bugs. Apart from that, you can also use it to explore the execution of a program, since you can freely step backwards and forwards in time. You also get a deterministic thread execution sequence each time. That might be either good or bad, depending on what you want.