Diagram size vs single-use sub-vi

[JeffBuckles]

I'm guessing this has been beaten to death elsewhere but I could not find it...

I feel like I've been accumulating conflicting messages:

- block diagram should fit on one page

vs

- don't create sub-VI's just to save diagram space

 So, now I'm in a situation where I have a case frame that calls one sub-vi to do "X".   And because of an added feature I need to  add inside the case frame another instance of "X" with different inputs -- that is, the same function needs to "do more".   But the frame is already "full" and I would have to enlarge the diagram beyond the visible page to make space.   

Now, I wonder if the admonishment against using sub-vi's to save space is only to prevent users making a sub-vi with a random collection of un-related functionality?  Because in this case it is more an "extension" of existing functionality.  So if I pushed this down into a new sub-vi it would contain related logic: the old functionality with the new feature added.

I'm just thinking about this because someday someone else may have to look at this and I don't want them to have to spend days just to understand what I was trying to do.   Or, worse, have it end up in the R-G thread.

A small detail it is, but many small details can make a big mess...

Thanks and Best Regards,

-- J.

[LV_Pro]

Well, there are no hard and fast rules regarding fitting on the diagram vs. sub-vi's. I'm not sure where you have heard that it isn't a good idea to create a sub-vi when a diagram's  has grown too complex. You don't want to just "encapsulate" random bits of code, but if you a some functionality that needs to be repeated that sounds like the appropriate time for a sub-vi. There is a reason that NI gave us the tool to select a part of the diagram's code and automatically create a sub-vi. As to a diagram being too big to fit on the screen, even that is vague, having definitely changed from the days of 13" Crt monitors at 640X480, to 24"LCD 1920X1200!

As to having someone following you understand your work, comment your code, comment your code, comment your code!

[RavensFan]

Some people might like to believe that trying to keep the block diagram so it fits entirely within one screen is a hard fast rule.  But that is kind of ridiculous.  You often can't.  It is just matter of not having a program to blow up to multiple screens with disorganized spaghetti code.

If you need to exand a structure to fit in a new subVI and it causes the diagram to reach beyond the screen edges, then do it.  It is more important for the subVI's to make sense in their modularily rather than mashing together unrelated code just to save screen real estate on a larger subVI.

Message Edited by Ravens Fan on 12-14-2009 09:45 PM

[tst]

The fact that you SHOULD create subVIs to clear up the diagram is so obvious that most people who tell you NOT to do it probably don't even realize that they and every other programmer in every language do it all the time.

A VI doesn't have to be reusable at all (although code reuse is the most obvious candidate for creating subVIs). It can (and should) be used to hide the details of a certain task from the calling VI if those details are unneeded in the calling diagram. Of course, as you and the others pointed out, it should not be created from random pieces of code but from tasks which have meaning. Ideally, what part should go into a subVI should even be decided before you write the calling VI, but there are certainly cases where you might realize "Oh, this piece of code is actually more complicated than I originally thought. Let's hide it in a subVI".

Incidentally, I also agree that it's better to let the diagram grow bigger than the screen than move stuff into subVIs unnecessarily.

[Norbert_B]

---

JeffBuckles wrote:
[...]

- don't create sub-VI's just to save diagram space

 [...]

---

J,

you are talking about style guides so this is no rule, but a guideline. As a guideline i would suggest the following:

- If you have code which is occurring on several places in you VI (redundant), you have to encapsulate it into a subVI (building reusable modules as target).

- If the block diagram grows too much, you can/should encapsulate code which is complex/taking much space for its functionality

- If the block diagram grows too much, make sure that it is scrollable only in one direction (horizontal or vertical)

As tst already stated: Building subVIs just to save space requires "intelligent selection of what should be part of the subVI".

hope this helps,

Norbert 

[oyester]

Don't think in terms of saving space. Think in terms of making the code more readable. For example, f you can isolate a chunk of code that does only one thing, then isolate that chunk of code and convert it into a subVI. Give it a strong name that describes what that one-thing-that-it-does is and make sure that the inputs and outputs have clear, descriptive names. What you end up with is a back panel that is easier to understand and the savings in space is a nice side effect.

[JÞB]

Lots of good points from all over!.

Create a sub-vi whenever

A) You can abstract a chunk of code that you can name.  e.g "Get Reading.vi"or "Set Output.vi"

B) You can encapluate related Functions or data elements. e.g. or "DUT State Cashe.vi" with modes<Get |Set | Init> to operate on the same data

C)You Identify a group of operations are logically related by data or timing, that is to say ther are Coherent.

D)You can imagine Reuse of the same code in a number of projects (look at Time to Excel.vi  below)

Good developers learn by practice just exactly when to break out a sub-vi.

Great developers pull out their hair triing to figure out how their own code, that they wrote as newbie, ever worked.