可视化 Python function 流（例如作为树或概念图）

Question

I have taught myself python in quite a haphazard way. So my question perhaps won't be very pythonic.

When I write functions in classes, I often lose overview of what each function does. I do try to name them properly. But still, they are sometimes smaller parts of code where it seems arbitrary in which functions to put them. So whenever I want to make changes, I still need to go through the entire code in order to figure out how my functions actually flow.

From what I understand, we have objects and we have functions, and these are our units for structuring our code. But this only gives you a flat structure. It doesn't allow you to do any kind of nesting, like in a tree diagram, over multiple levels. Especially, the code in my file doesn't automatically water itself so that the functions that are called first and more often automatically further up on the top, whereas helper functions would be automatically further down in the document, or even nested.

In fact, even being able to visually nest lower-order subroutines "inside" a higher-order function that calls it would seem helpful. But it's not something that would be supported by Python's syntax. (Plus, it wouldn't quite suffice, because a sub-routine might be used by several higher-order functions.)

I imagine it would be useful to see all functions in my code visualized as a tree, or as a concept map:

Where each function is a dot. And calling order visualized by arrows. This way, I would also easily see which functions are more central, and which are more outliers, or even orphaned.

Yet perhaps this isn't even a case for another tool. Perhaps this is more a case of me not understanding proper coding. Perhaps there is something I can do differently in order to get the kind of intuitive overview over how my program works, without needing another tool.

Answer 1

Firstly, I am not quite sure why this isn't asked more often. Reading code is not intuitive, at all. We should be able to visualize the evolution of a process or function so well that close to every one will be able to understand its behavior, In the 60s and so, people had to be reasonably sure their programs would run; because getting access to the computer would take time, today we execute or compile our program, run tests if we have them. and get to know immediately whether it works, What happened is there is less mental effort now, we execute a bit less code in our heads. and the computer a bit more. But we must still think of how the program behaves midst execution in order to debug, For the future. it would be nice if the computer could just tell us how the program behaves.

You propose looking at a sort of tree of the program as a resolute, and after all, the abstract syntax tree is literally a tree, but I don't think this is what we ought to spend our efforts on when it comes to visualizing systems. What would be preferable is if we could look at an interactive view of how the problem changes its intermediate data-structures as a function of time.

Currently, we have debuggers--but that's akin to looking at the issue by asking what a function is at many values, when we would much rather look at its graph. A lot of programming is done by doing something you feel is right, observing if the behavior correct, if it's not correct then we make modifications by reacting and correcting said behavior.

Bret Victor in his essay, Learnable Programming , discusses this topic. I highly recommend it, even though it won't help you right now, maybe you can help others in the future by making these ideas more prevalent.

Onwards, then to where I tell you what you can do right now. In his book Clean Code, Robert C. Martin proposes structuring code much like how a newspaper is laid out.

Think of a well-written newspaper article. You read it vertically. At the top you expect a headline that will tell you what the story is about and allows you to decide whether it is something you want to read. The first paragraph gives you a synopsis of the whole story, hiding all the details while giving you the broad-brush concepts. As you continue downward, the details increase until you have all the dates, names, quotes, claims, and other minutia.

What is proposed, is to organize your program top-down, with higher level procedures that call mid-level procedures, which in turn call the lower level procedures. At any place, it should be obvious that (1) you are at the appropriate level of abstraction, and (2) you are looking at the part of the program implementing the behavior you seek to modify.

This means storing state at the level where it belongs, and exposing it anywhere else. Procedures should take only the parameters they need, because more parameters means you must also think about more parameters when reasoning about the code.

This is the primary reason for decomposing procedures into smaller procedures. For example, here some code I've written previously. It's not perfect, but you can see very clearly which part of the program you need to go to if you want to change anything.

Of course, higher order procedures are listed before any other. I'm telling you what I'm going to do, before I show you how I do it.

function formatLinks(matches, stripped) {
  let formatted_links = []
  for (match of matches) {
      let diff = difference(match, stripped)

      if (isSimpleLink(diff)) {
          formatted_links.push(formatAsSimpleLink(diff))
      } else if (hasPrefix(diff)) {
          formatted_links.push(formatAsPrefixedLink(diff))
      } else if (hasSuffix(diff)) {
          formatted_links.push(formatAsSuffixedLink(diff))
      }
  }

  // There might be multiple links within a word
  // in which case we join them and strip any duplicated parts
  // (which are otherwise interpreted as suffixes)
  if (formatted_links.length > 1) {
      return combineLinks(formatted_links)
  }

  // Default case
  return formatted_links[0]
}

If JavaScript was a typed language, and if we could see an image of the decisions made in the code, as a factor of input and time, this could be even better.

I think Quokka.js and VS Code Debug Visualizer are both doing interesting work in this sector.