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.

[Darin.K]

Are you surprised when you open a subVI and find code?  I doubt it.  Are you surprised when some For loops have code beyond the edges?  I guess not.  Not all non-visible code is hidden. 

opinions are like belly buttons, I simply will have to disagree on this one.  All uses I have heard feel like obfuscations and do not outweigh the real issues I have had.  

[Jeff-P]

I like this idea (or at least some form of indication that a structure is hiding code beyond its boundaries even though I know that was not what you were asking for).

...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?

I would argue that LabVIEW does tell you when code is hidden off the screen. Your scrollbars will resize depending on the size of the whole block diagram, and you can use the navigation window to see the full extent of the code. Structures do not have the same indicators.

For an extreme example, if I made a case structure the size of my entire screen and hide code in the corner before resizing the structure to be small, then that code will be extremely hard to notice. 

This makes the program next to impossible to troubleshoot. In my opinion this is not forcing people to comply to style as much as it is simply increasing the usability of LabVIEW as a programming language. It should not be possible to bury code with no visual indication that code is hidden.

Just my opinion!

Jeff Peacock

Product Support Engineer | LabVIEW R&D | National Instruments  

[Daklu]

Are you surprised when you open a subVI and find code?

No, but sometimes I find code on a block diagram that is well separated from the main part of the block diagram and is not immediately visible.  If I don't notice the scroll bars right away I'll be surprised when I discover it.

Not all non-visible code is hidden.

Fair enough--I agree.  In your opinion what's the difference between non-visible code and hidden code?  Seems to me the only difference is "hidden code" is located somewhere on the block diagram a person doesn't expect there to be any code.

All uses I have heard feel like obfuscations and do not outweigh the real issues I have had.

That's not surprising.  If you reject the use cases X and I have presented as valid reasons for code to exist beyond the structure's edges, then of course they won't outweigh the issues you've run into.  I'm not asking you to adopt the development practices and coding standards I find most productive.  I'm just asking you not to make it harder for me to solve my problems simply so you can solve your problems more easily.

---------------------------------

I would argue that LabVIEW does tell you when code is hidden off the screen.

Sure, LV provides a visual cue to indicate code exists somewhere off the screen and I didn't mean to claim otherwise.  Code off the screen is invisible in that it isn't visible right then.  It will stay invisible until the user takes some action to make it visible on the screen.  Some parts of Labview do a reasonably good job of making invisible code discoverable.  (Block diagram scrollbars, the list of frames for case structures, etc.)  Other parts do a very poor job of making invisible code discoverable.  (Code beyond the structure edges.)  None of it is invisible to the extent that it can't be viewed.

I'm all in favor of having some sort of visual cue on the structure borders when non-visible code is present.  (Heck, maybe even scroll bars!)  But Darin has specifically stated he does not want a visual indicator, he wants to prevent code from even existing somewhere beyond the structure's edges.  Why are visual cues appropriate for the block diagram but inappropriate for a structure?  I'm asking for a justification for this idea as opposed to the visual indicator idea.  So far the only justification I've seen is Darin wants it.  (No disrespect intended to Darin.  I've had my share of ideas that unintentionally sacrificed someone else's workflow so my workflow is simplified.)

[donkdonk]

@Daklu

[..]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? [..]please don't impose your style and standards on the community as a whole.

I agree the propsed idea is a style. But I think a lot of styles are "imposed" to us, LabVIEW users. And that gives as a clue what is going on. Suppose we were allowed to repaint all the wires to the color we please, restyle the for loop to mimic the looks of a case structure, restyle the diagram icons to look like smarties or polar bears or whatever.

All these changes would semantically be identical and the vi would run. However, I think not many users would like NI to implement the proposed freedom.
It is for this reason I hesitate to kudo ideas that propose the looks of a for/while loop to be customizeable.

Yes, style is something personal but wo cannot do without and we'll have to agree on something that works for most people.
That being said, I am not sure yet to kudo the do-not-hide-code-in-diagrams-idea (I lean toward kudoing).

[Darin.K]

For various reasons, I can not fully discuss my current, tangible motivation for this rule.  But I can cover some of it in more abstract terms.

Regardless of what hocus-pocus Visual Studio or other IDEs let you do when displaying the source code (fonts, etc), I can open a C#, C++, Python, PHP or whatever file in an ascii text editor and get a full and complete understanding of what the code is doing, limited only by my understanding of the language (assume it is perfect, it is far from it, but just for arguments sake).  I know what headers or packages need to be examined as well.  I can do whatever QC, or other validation and record keeping which is necessary.

For LV, it is impossible to do a similar process.  Using an IDE is not an option.  The image must become the equivalent of the ascii representation of the source code in text languages.  What you see must be what you get.  Of course, there are ways to hide information, but I can create a few rules to counteract most of them.  Numeric constants must show radix, array constants must either show all elements or be loaded from a file which is provided in ascii format, strings must show their scrollbar, and must show that the scrollbar indicates no hidden text.  All of this is for naught, hiding code beyond structure boundaries is too big of a loophole.  This does, in a way, make this job easier.  LV?  no way.

In 20+ years my workflow has been jerked around more times than I can count.  Most people have not had an upgrade basically invalidate an entire code set.  As much as even that sucked at the time, it was well worth it in the end.  I think this is a modest tweak to the representation of the G code, no change at all to the syntax of the underlying code.  The long term benefit is not in special cases like mine, but in always being able to look at a block diagram and knowing that what you see is what you get.

Of course when force modelling is introduced, hidden and even obstructed code should be a thing of the past.  Sounds like I will be much happier than others when that day comes.  I have never understood why nodes were not treated as rigid bodies to begin with.

[fabric]

My initial reaction to this idea was strong aversion. (The last thing I want is my carefully arranged diagram exploded into oblivion just because I expand a cluster constant...)

After sitting on it for a while I have reached a more mature stance: I would consider supporting for this idea, but only after the various loopholes are closed that cause this particular idea to smell funny. Which loopholes? Many have already been mentioned:

• Editing long strings/paths should not explode my structure
• Typing a long comment (which I intend to resize to multi-line format) should not explode my structure
• Auto-placing of terminals for FP objects should not affect my BD layout
• "Pasted code" should stay on the cursor until placed
• Auto-grow needs auto-shrink, and possibly should allow constraining to 1D

IMO forcing a radical change like this should not even be considered without appropriate damage control in place first.

[tst]

---

@fabric wrote:
IMO forcing a radical change like this should not even be considered without appropriate damage control in place first.

---

Then might I point you back to the original idea? Your objections there, as here, seem to be exactly about LV playing with your code, but if you're considering letting LV do some of the work in fixing the issue, then that one might be more down your alley.

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

Of course, it has its own issues and maybe it will need exceptions (such as ignore locked VIs or vi.lib VIs or any VIs located in other excluded folders), but it still is less intrusive in terms of auto-modifying code.

Incidentally, your own idea is currently four times as popular as either of the other two, so even if NI did do something about this, it's quite possible they would go that way.

[SteenSchmidt]

I strongly disagree with this idea. I agree with Dave, a visual cue is they way to go, as with all other temporarily hidden code (the BD as a whole is a brilliant example). I also sometimes temporarily hide code in a shrunken structure (somehow that sentence just sounds wrong ). The use case is 90% of the time debugging, where I need some temporary debug code to fit in a small space. In this case I often don't want to make a subVI for a number of reasons; it takes time, the code isn't reusable anyway, the project dependencies list gets messed up, the last_saved_at path gets changed, there might be a call overhead or code impossibilities (e.g. property nodes), etc. etc.

It could also be a Diagram Disable structure that lives only while different algorithms gets investigated. In this situation I postpone final style application until I have decided on which code to keep, so code in the frames of my Diagram Disable structures is often quite "exploded", making it handy to temporarily being able to shrink it - the entire structure will be gone from the final code anyway.

And what happens when you paste in a code snippet that doesn't fit inside a given structure? Not all code snippets should be inside a subVI. It can be bad style to copy code, but sometimes it's the proper thing to do. And in that case I don't want my code snippet to get compressed by the structure it ends up in, and I don't want that structure to autogrow either. What I'd really like is for the structure to tell me that some of my code snippet ended up outside its current border. Now that'd save me some time once in a while.

I should repeat my statement from that other thread:

I definetely do not want my code to break just because it's hidden. Bad bad style, yes, but not broken.

Breaking code based on hidden graphics would to some extent compare to a C-compiler refusing to compile a source file if you didn't wordwrap long lines that stretch outside the display border. The LabVIEW IDE is an editor. It should provide us with visual cues that we are making a mess at editing, but it shouldn't break our code based on this. If it did so we would definetely have an impossible task explaining the difference between MS Paint and the LabVIEW IDE. That would be too tight a bound for my taste ("Oh, I found out why your compilation took so long; you've colored this subdiagram RED. Silly you!").

/Steen

[Manzolli]

Hidden code maybe good for some people in some very special situations. In general, hidden code may lead to misunderstanding the behavior of the VI. I don't like the "hidden" code under Stacked Sequence and Case structures. The 1st we can replace by the Flat Sequence the second we should live with. Kudos!

[jmorris]

I am firmly in the no-autogrow camp, and I like this idea (although I would also be happy with some of the other proposals such as visual indicators).  I would point out (as others have in the comments) that common use cases like typing a long comment that I intend to resize has to work in a reasonable way (I would expect it to extend into the hidden area, and the VI to in response become broken until I correct that.  I would argue that for the autogrow-off case moving VIs and primitives should work the same way - you can move them beyond the visible area, but the VI will be broken as a response, and the error dialog will highlight the issue and jump you to the hidden code.

With regards to whether this is a good enough idea to enforce on everyone, I agree it is not.  I believe that people should be able to choose to hide their code if they want to (temporary debugging was a good example of when it might be useful / legitimate).  However, there is an easy solution to not impose while still offering this very useful functionality - make it an option / preference.  Taking that to the extreme would allow setting a global preference while also being able to turn it on or off on a per-VI basis via the VI properties, but I don't think that would be necessary.