Automatic make subVI map

[EngrStudent]

Background: 

So building off of this (Very-simple-improvement-on-Block-diagram-clean-up-OPTIONS)

I am making VI's like this:

They have many single frames floating around, some nested.  Nearly none are sequential.  Inside each frame is a complete "logical unit".

Observation:

I find that when I make my whole code like this, candidates for being converted to Sub-VI are obvious.  They have more wires going in, more stuff going on, nesting, and it is all in the same box.

A good example of what they look like when done is this (thanks X.):

Often I don't know what the "done" version looks like until I work through the bugs, requirements, refinements, and unhappy-paths of the "rough" version.

Suggestion:

1. I think that I should be able to make a mostly hairy mess, but with the key point that inside each frame is a chunk of code that humans need to see all at once to understand how it works - AND THEN - LabVIEW should be able to look at the overall layout and pick which boxes make the best sub-VI's.  I'm thinking boxes where marginal cyclomatic complexity makes big jumps might be a good starting criterion. [Cyclomatic complexity (link), Essential complexity (link)] - Let me ask you this: "Is there a variation on cyclomatic complexity that has meaning only in a visual programming language FOR WHICH FRAME ARE SUPPLIED THAT DEFINE BOUNDARIES OF COMPREHENSIBILITY (as shown above)?" I could see this like a variation on the comment section of slashdot - where there are sliders that show level settings for abbreviated or hidden, except operating on complexity and allowing transformation of the full project.  
   
   
   
   
2. If think that if there are 20 wires coming out of one Sub-VI and going into another - that the automatic process should bind them into a big cable (cluster, array, whatever) that is most efficient.  This way my sub-VI only needs one i/o wire to communicate with its buddy and not 200.  I think that a new control i/o "pin" should be used only when 1) it is specified by the user as a unique I/O or 2) when it routes to a different sub-VI. In cyclomatic complexity they talk about only one entry 

[Intaris]

Moving wires into a cluster only for transport into / out of a sub-VI is not always efficient.  It can cause buffer allocations which is a bad thing if it's not neccessary.

[X.]

First of, you need to learn concision (I am the wrong person to give this advice, but it is a good one nonetheless).

Brief abstract, a few figures at most, and a Suggestion in bold.

Then comment ad libitum in subsequent posts to expand on the main idea.

Now, regarding the suggestion of letting LV do the subVI creation automagically, you probably haven't noticed yet how miserably LV's algorithms fail to do what the user wants, for instance when creating subVIs from a selection and messing up the order of inputs and outputs... I am not even talking about... OK you know what.

This being said, I would be concerned that what is "logical" for an algorithm to group together, might not be what the programmer would expect or prefer. This would in the worse case result in code that would in fact be almost indecipherable to a human being.

As for wire bundles, I occasionally have a big untangled mess of wires when I DON'T WANT to use subVIs to avoid making copies of large data sets. I would argue that if such is not the case (the data is lightweight) then it might be worth creating clusters of them in the first place. But letting an algorithm figure what should be logically associated with what? I don't think that AI has reached a level yet where it could be successfully done. Or at least done successfully for you AND me at the same time.

[Darren]

Any idea that has not received any kudos within a year after posting will be automatically declined.