Structures should not be allowed to hide code in diagrams!

[Darin.K]

The crux of this idea is a very simple premise:  Structures should not be allowed to hide code inside their diagrams.  Ever.  Period.  There is no legitimate reason.

The rest is implementation details which are negotiable, unlike the basic premise.

With Autogrow enabled this is not an issue.  So it could be as simple as removing the option to turn it off.  I would prefer a slight alternative, allow autogrow to determine two different behaviors when an object pushes against a structure boundary:  Autogrow = object wins and structure grows.  No Autogrow = structure wins and object no longer moves.  All structure growth is done by hand in that case.

When upgrading VIs which have hidden code, I suggest a one-time autogrow.  Breaking code could be an option ( ), but that would simply force the user to autogrow or cleanup the BD anyway.    If there are other errors, a broken run arrow is not a clear, direct indication anyway.

There could be a corollary preventing hidden code in general.  I may not agree with them, but I do see that there could be an argument there to allow hidden code in some cases.  That battle is being waged elsewhere:

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/LabVIEW-should-break-VIs-which-have-hidden-code/idi-p/...

I see no reason, however, to allow the bounds of a structure diagram to shrink beyond the bounds of its content.  Nefarious reasons? yes  Legitimate ones?  not that I can think of.

I empathize and support this idea as a start:

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Visual-indication-that-a-structure-is-hiding-code-beyo...

But I do not want a visual indication, I want to know by construction that nothing lies beneath.

[M_Peeker]

Best and simplest suggestion on this matter yet! Kudos!

[vitoi]

I've given the idea kudos since I also hate hidden items. However, I hate autogrow more, so defiently want to be ble to turn it off.

I spent alot of time getting my diagrams right. I don't want LabVIEW to screw this up.

[X.]

There are different kinds of personalities. I don't feel like hidden things are (always) bad. Or proprietary code. Or backdoors. Or bugs. Just let me know they can be here and allow me to figure out where (the suggestion you linked to).

[Darin.K]

@vitoi:  I do not want to argue too many implementation details, but is my suggestion that autogrow off stops objects instead of letting them slide into oblivion acceptable to an autogrow off person?  The only time you would see an autogrow is upgrading old code which hid something.

@X: I do not know what it is right now, but there has to be much better solutions to that problem.

[jsiegel]

What would happen if a created control/indicator/constant is too big for the structure in which it would reside?

[Darin.K]

> What would happen if a created control/indicator/constant is too big for the structure in which it would reside?

An implementation detail, probably one of the stickiest since the whole create constant/indictor function is about as big of a mess as the create space function.  Someday there will be a physics-based layout and everything will be cool and will dynamically adjust.  Until then,

If autogrow is on, obviously it would grow to accommodate the new object.

If autogrow is off, I'd suggest cramming it in.  It may have to overlap something, it may have to take up all of the room even.  My thinking is that you turned autogrow off so you are responsible for cleaning up the mess.  The structure may have to grow to accommodate the new object if it is too small.  I doubt it, there is a minimum size to most structures.

Again, implementation details are TBD.

You have given me yet another idea.  Stay tuned

[GregFreeman]

Well, if you just run the VI An--...ok, kudoed. 

[Daklu]

---

Darin.K wrote:

The crux of this idea is a very simple premise:  Structures should not be allowed to hide code inside their diagrams.  Ever.  Period.  There is no legitimate reason.

---

That's a strong assertion.  Perhaps unsurprisingly, I disagree with your premise and, therefore, oppose the idea as a whole.  As a matter of fact, occasionally I purposely reduce a structure's size so code ends up hidden behind edges.  I don't do it often, but it's a handy trick to use when the situation calls for it.

Case in point, imagine you're trying to debug some code with a fairly densely packed diagram.  For whatever reason, you can't get the information you want using a simple probe (maybe the wire is for a reference data type or you need to preprocess the data to extract useful information) and there's not enough room to add the debugging code without rearranging the block diagram. 

When I run into that situation sometimes I'll throw the debug code in a structure, shrink it down as small as possible, and squeeze it somewhere in the existing code.  It's not the only option.  I could also create new probes, wrap the debug code in a sub vi, send the wire into a global variable and extract my debug info in some other code altogether, or use any of several other techniques.  Each technique has strengths and weaknesses.  It's the developer's job to understand the tradeoffs and choose how to implement the debug code.

That's an example of a legitimate reason to hide code inside a structure diagram.  However, even if I didn't have a legitimate reason to hide code in a structure I'd still oppose the idea.  The essence of my objection to this idea (and many ideas proposed on the exchange) is that it strictly enforce one set of style guidelines.  Style guidelines are exactly that--guidelines.  Following or not following them should be left to the developer's discretion, not enforced by the environment.

[Darin.K]

This is not meant as a style guideline, this is meant as a contract between the LV IDE and myself.   The benefits to me are that a simple, uniform rule is easy to remember and easy to apply.  It also means that in exchange for me not being able to hide code, the IDE will not do it either.  I can look at a diagram and not give any thought to what may lurk beyond.  To paraphrase Johnny Dangerously, "That developer gave me a VI with code obfuscated inside a sequence structure once, ...once."

Since subVIs are smaller, reusable, smart insertable with Quick Drop, and have the nice option to suspend when called I can safely say that I never have or never will cram code into a  structure and wedge it inside a block diagram.  Would I make an exception to a rule to accommodate that type of use case?  Personally, no, especially when I happen to think much better, and more natural alternatives exist.

[Daklu]

This is not meant as a style guideline...

It may not be meant as a style guideline, but that's exactly what it is.  All other things being equal, there is no semantic difference between visible code and non-visible code.  If there is no semantic difference, then by definition it is style.  Why should the IDE impose a restriction on implementing non-visible code that is otherwise completely valid? 

Your justification for the idea can be applied equally well to individual vis; after all, a block diagram is effectively just a large structure.  Code that is off the screen is effectively invisible.  Should Labview prevent us from reducing a block diagram window's size to something smaller than code on the block diagram or scrolling existing code off the screen?

Since subVIs are smaller, reusable, smart insertable with Quick Drop, and have the nice option to suspend when called I can safely say that I never have or never will cram code into a  structure and wedge it inside a block diagram.

Most of the time I use sub vis too.  Sometimes there are reasons not to.  Maybe I need several versions with slightly different implementations and don't feel like creating a bunch of new vis that are going to be discarded in 8 minutes.  Maybe the debug code needs to access a bunch of front panel references and there's no room to bundle them all up into a single wire.  There are lots of reasons why someone would choose not to use a sub vi in a particular situation.

I think I understand why you requested the feature.  You've run into issues with hidden code causing a problem and/or you don't want to have to verify there is no code beyond the edges.  (I'm just guessing though.  You never actually stated what problem you're trying to solve.)  I've been bitten by code beyond the edges before too and agree it can be a pain to find.  However, these comments,

...I want to know by construction that nothing lies beneath.

...this is meant as a contract between the LV IDE and myself.

...I can safely say that I never have or never will cram code into a  structure and wedge it inside a block diagram.  Would I make an exception to a rule to accommodate that type of use case?  Personally, no...

illustrate just how much this idea is tied to your style, preferences, and coding standards.  I have no issues at all with the choices you've made.  If that's what works for you that's great.  But please don't impose your style and standards on the community as a whole.