Two related questions: • Is there any good research about using call graphs to create some metrics about the quality of a software architecture? (Since I've never looked into it — what's the state-of-the-art in measuring software quality, anyhow? I'm more interested in a quality architecture than bugs-per-line-of-code or something, I guess.) • Any favorite tool for visualizing call graphs for JavaScript or PHP? My intuition would tend to say that messy call graphs indicate a worse architecture, but I haven't visualized many and I'm not sure how well that idea holds up in the "real world". Maybe call graphs end up being too messy in real programs.

As for measuring software quality (which is deceptively subjective), there's a list of metrics here that might be a good starting point.

Yeah, I know it's terribly subjective. I perhaps was thinking something along the lines of measuring complexity or coupling? Hmm…I think I want less of a metric and more just a visualization. If I'm solving a simple problem, the solution should look simple when visualized. Does your repo of visual programming languages also include program visualization, @Ivan Reese?

Sounds like https://en.wikipedia.org/wiki/Cyclomatic_complexity

@David Alan Hjelle No, my repo doesn't really include that, but it is adjacent / related. @Tom Larkworthy Yeah, that wiki link I shared was the result of me thinking "this sounds like cyclomatic complexity — I wonder if there's a whole category of these", haha.

Isn't cyclomatic complexity more about control flow (i.e., according to Wikipedia, if the program contained no conditionals, the cyclomatic complexity would be 1)? I'm thinking more about when you organize a imperative program into functions, and measuring more the relationships and coupling between those functions. (I bet some of those other measures get into that sort of thing…I'll have to do some reading,)

Right, that's the subjectivity. What does one care about when assessing quality? By some criteria, if two programs perform the same job but one of them has lower cyclomatic complexity, that's the superior program.

Yeah, totally. I think that's where I wondered about call graphs explicitly — my 20 seconds of experience yesterday making one hinted to me that, given a particular problem, a "cleaner" (again subjective) call graph is the better program (to me). I think I really don't care about a metric so much as some sort of tool to help me help other developers write better organized code. A call graph might be one — if there was a good, reliable tool for such a thing — but maybe there are others? In general, I'm surprised that program visualization—for our existing programming languages—isn't a more common thing? Or am I just not in the right circles?

You're 100% right — program visualization is not nearly as common as it ought to be.

yeah cyclomatic is supposed to measure the underlying computational complexity, not source code organisation. There is another one for code organization... I am not sure now, maybe LCOM4? But then I remembered SOLID and feel like those are quite good principles that should and probably do have metrics (?). I dunno why we do not visualize code more, can't say I have used it since leaving university 🤷‍♂️ Maybe the value is too indirect for the business people that prioritise (?)

I recall a cool trick to find bad code organization based on git commits. It went roughly like that: (starting assumption) When you do an incremental change in a system, in a well-organized system you would only have to change the source of one function - the function responsible for the thing you want to change. Also many different changes shouldn't all concentrate on the same function because it hurts code reuse. This sounds pretty ambitious and doesn't really hold in any real system BUT it can be used as a proxy to find problematic areas. Take a look at a git log. If there are groups of functions that are usually changed together (in the same commit) - then it means that they share something that could be extracted into a common location. Also any place which is a hotspot of changes (almost every commit touches it) then it probably could be split out. All of this can be formalized as counting bigrams of functions changed in the same commit. I've done some stats like that on a large-ish project at work and the hotspots (functions which were changed in commits) followed something similar to the zipf distribution. It didn't made sense to split everything but it showed some very interesting correlations that nobody had idea about (even the people working on the system).

@Marek Rogalski There’s a book called Your Code as a Crime Scene that I think covers what you’re talking about (here’s a blog post by the author that later was expanded into the book) There’s an open source tool called codemaat that does a lot of the analytics (and the book covers how to make the visualizations of the data codemaat spits out.)

I haven't tried this, but it's a VS Code fork that can lay out code in a call graph style: https://haystackeditor.com