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.<p>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.<p>I generally want three kinds of things in my head when reading code: control flow, data flow and data shape.<p>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.<p>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.<p>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.<p>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.
As someone looking in from outside, the Chrome codebase is a treat. Anecdote.<p>Once during the start of my career I was asked to implement a caching layer in an HTTP library. I had no idea what it was, so there was some reading up to do. There were the excellent guides from mnot.net, as well as the nicely written RFC 2616. But Chrome's code was the best of all - <a href="https://github.com/adobe/chromium/blob/master/net/http/http_response_headers.cc#L990" rel="nofollow">https://github.com/adobe/chromium/blob/master/net/http/http_...</a>. If you want to know for a fact how Chrome decides caching, that code is kind of the heart of it.<p>Recently I needed to retrieve the "Rendered Font Name" that is available in the DevTools "Computed CSS" section. This is the name of the system font that Chrome finally picks, based on the Font-Family property. This is platform specific and so not in DOM, nor available to Chrome Extensions directly. The only way it could be done was by making an extension running in debug mode and communicates to the browser thru its remote debugger protocol. (This part of the documentation is lacking, but it is an esoteric topic anyway). The good news was that the code that does this is well encapsulated and could be easily extracted into a command line utility. For the curious: <a href="https://chromium.googlesource.com/chromium/src/+/master/third_party/WebKit/Source/platform/fonts/mac/FontFamilyMatcherMac.mm#129" rel="nofollow">https://chromium.googlesource.com/chromium/src/+/master/thir...</a> (there is a nugget about real-world software in the comments)<p>This is, at a surface level, good code to me. Things are easy to find, there is a rhyme and rhythm to the system, and feels welcoming. The thoughts of the people who designed that system over years would be great to hear.
Most writing about good code on the internet comes from an OO background, mostly wrt information systems. I wonder what people who've written these systems have to say about building and engineering complex software.
The visualization aspect looks quite interesting, but I'm not sure how many things this can do that a quality IDE already doesn't.<p>The example uses the author mentions ("Following code paths from method to method", "Finding where an interface is implemented and which methods get overridden", "Exploring dependencies between types and functions") all sound like pretty standard features today. Plus with an IDE you get the benefit of having them right there in the editor/debugger/etc. and much more.<p>I would however really like something for inspecting the <i>run-time</i> structure of an application's objects. Most debugger views are really clunky for looking at large amounts of data, and even the pretty-print features often don't help much. Having a zoomable graph with the objects right there in front of me would really bring my productivity to the next level.
I see comments that "an IDE can do this". Perhaps so. But there are lots of data-discovery missions where you need to learn a codebase quickly that you won't be fully compiling or building yourself. Perhaps you need to replicate an approach, or understand where something in your code needs to change in order to work with the other code that you can't touch. Tools like the OP's could become very handy in understanding a codebase without bringing the entire thing into your IDE.<p>I agree that some pieces only are really comprehensible runtime, but I applaud tools that reflect the need to learn a codebase without necessarily having to (or being able to) bring all the code into your IDE.
I feel obliged to mention this talk by Zed Shaw: <a href="https://vimeo.com/53062800" rel="nofollow">https://vimeo.com/53062800</a><p>It gives an overview and interpretation of a body of neuroscience research in the context of teaching programming. I can't quite summarize the whole talk succinctly (and don't want to lure anyone with catchy titles either) — but my takeaway from it is that those "visual" programming tools are mostly useless and not going to help significantly.<p>The reason for that being how the brain works: switching back and forth between "visual" and "linguistic" cognition is hard, and requires specific training to do efficiently. Please turn to the talk for references.
Trial does not allow to try it... You can only try it on some predefined small projects.
As I understand the only option for me to try it is to buy a license. Ok, author says that I can get refund in 1 month if I will not like it. But anyway - too much movements for trying.
Author please consider to actually give an option to really try it.
Another: please add retina icons.
Chromium Code Search sounds sort of similar to Hoogle. Can anyone with experience of both confirm this?<p>Also -- sort of offtopic, but motivated by TFA -- I'd love some way to find out about quirks that native speakers of $lang have when they speak $otherlang.<p>A few common "tells" that I know, for $otherlang = Englishf are Hyphenating-Things-Like-This and also spaces before exclamation points or question marks !
This company is tackling the same problem with a slightly different approach. I like that they have made their tools open source and modular. Theoretically you can use their system with any language by writing a few modules.<p><a href="https://sourcegraph.com/" rel="nofollow">https://sourcegraph.com/</a>
If it was hosted, and you could point it at a GitHub repo, I'd use it.<p>Otherwise I'd rather use whatever IDE JetBrains has for it. It might not have the exact same capabilities (or maybe it does, I didn't look closely enough) but why use another tool and context if the current one is good enough.
This reminds me a little bit of the IDA disassembler. There are moments where you might face production issues with external JS code and have no source maps available. A tree view to dissect what is going on would be useful in these situations.
This is really cool.
One killer feature that I don't know if you have considered is some kind of visualization of the stack trace, showing how control passes between the objects & functions. That would really help with dynamic languages, or large codebases that have been Greenspun-d heavily.
It would be very difficult to implement, especially in a cross-platform way, but I bet if you pick a language community like c++, java or something else and focus on it, you might have better results.
This tool looks quite useful for weird build environments with tons of completely undocumented native code such as AOSP (Android) where IDEs regularly fall over.
Java provides an easy way for tracing control flow during program execution:
when I join a new contract and am responsible for maintaining legacy java code, I use AspectJ with logging aspects with before and after pointcuts. This helps me figure out the application control flow.<p>I wonder if something similar is available for C/C++.
How does it compare to Google Kythe (internally known as Code Search): <a href="https://github.com/google/kythe" rel="nofollow">https://github.com/google/kythe</a>?