LabVIEW should break VIs which have hidden code

[tst]

There is something wrong with this VI, although you wouldn't know it unless you ran it (and I should warn you that it will annoy you if you run it):

What's wrong with it is that auto grow has been disabled and there's some annoying code hidden there beyond the loop boundary. This is one of my least favorite things about LV - it allows us to hide code completely and get away with it. I don't think it should.

LV already has auto grow enabled by default to handle some of the cases which cause this issue, but I know that many many people don't like it when LV automatically plays with their BD layout (and rightly so) and auto grow only covers some of the cases, so I think we need something more encompassing and less obtrusive, and I would suggest breaking the VI if it has hidden code.

I also know that LV has warnings and VI Analyzer has tests for this, but I think this needs to be something which doesn't let you get away with it.

I think LV should break any VI which has any of the following:

• Objects beyond the visible boundaries of structures (including wires and constants).
• Objects behind other objects (possibly not including wires).
• Overlapping tunnels on structures (or maybe just not allow them to overlap at all)?
• Anything else?

[tst]

I agree that there's a problem with the warning system, but I don't think that filtering the warnings will necessarily be enough for something like this.

In any case, there is already an idea for filtering warnings - http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Allow-me-to-selectively-ignore-warnings-in-the-Error-L...

[BillMe]

I kudo'd this because I look at it this way: How many times have you seen hidden code in a text based language (disregarding the infamous obfuscation contests)?

I agree that a solution that prevents the possiblity of hiding code is sorely needed. That leaves WAY too much room for abuse otherwise.

I would be happy with a pop-up warning when LV loads a VI that has hidden code, OR better yet, having LV move the hidden code to make it visible. It doesn't have to break the VI for that.

[AristosQueue (NI)]

I think this Idea might be better as "add indication to the border of structure nodes when things are hidden under the edges" instead of breaking the VI. We don't want to break existing VIs when users upgrade to the next LV version, and lots of VIs have hidden code. To fix that, we would end up adding an option to "allow hidden code on this structure", which is functionally equivalent to the already existing option to turn off auto grow.

If we just add an indication that there *is* hidden code, then you can see that. And I think that might be valuable in the long run... BillMe asked this question:

> How many times have you seen hidden code in a text

> based language (disregarding the infamous obfuscation contests)?

My answer is, "More and more frequently."  Here's a screenshot I grabbed from VisualStudio today:

More and more, the details of code are folded up, hidden away, and only the important parts are shown most of the time. I've seen text editors that will give you views of your code with all the error/exception handling removed. LabVIEW itself introduced the "view cluster as icon" feature because people said that the values in the cluster were not needed to be viewed all the time. That's a feature that I have a major problem with because the icon view does not visually indicate "this cluster has a non-default value". I think that is exactly analogous to hiding code under the border of a structure. It's fine, as long as there is a visual indication that there is something hidden.

So, for the spirit of the idea, kudos from me. For the actual implementation of "break the VI", I have to withhold kudos.
 

[tst]

AQ, this isn't only about structures. There are other ways to hide code (such as under other nodes or VIs) and I've seen it happen numerous times. Likewise, a simple visual indication isn't enough, because the hidden code might be several layers down. A warning might do if the warning system worked properly and didn't flood you with too much details.

Also, I don't consider the VS example you gave to be hidden code any more than I consider a case structure or a subVI to be hidden code. That example allows you to hide the detail, but it's still clear the code is there and looking at it is easy and built in. A more equivalent example would be if VS allowed you to change the font color of some of the code to white on a white background.

I agree that legacy code would be a real issue with the actual idea implementation I suggested, but I still don't have a better idea for how this problem could be resolved and maybe requiring people to go through and clean their VI would be a good thing.

Maybe this could be implemented as a boolean environment option or a slider which will say how many infractions you allow before breaking the VI, similar to some of the settings VI Analyzer has. Then, you set the first version to be relatively tolerant by default, but as time goes by, you increase the default strictness (or alternatively, you set it to be very strict immediately and require experienced users to either fix old code or find the setting and explicitly set it to be more tolerant).

Also, for your spirit-of-the-idea kudos to actually work, I would suggest you actually give them and then let the actual details be sorted if/when the idea is reviewed.

[AristosQueue (NI)]

> Also, for your spirit-of-the-idea kudos to actually work, I would suggest

> you actually give them and then let the actual details be sorted if/when

> the idea is reviewed.

Too many good ideas already fleshed out. I save my kudos for those. 🙂

[tst]

The idea for the structure border highlighting can be found here - http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Visual-indication-that-a-structure-is-hiding-code-beyo...

[Daklu]

Put me firmly in the camp of those who do NOT want hidden code to generate a compiler error.  I routinely route wires behind structures because it reduces unnecessary clutter and (imo) is much easier to read.  While I appreciate the difficulty in debugging extensive hidden code, choosing whether or not to implement hidden code is purely a style decision.  The compiler should not be used as a style enforcement mechanism.

To answer the most obvious question, no, I do not have any nodes behind the structure; its just straight wires.  But I also won't claim it never makes sense to put a node behind a structure.  Maybe there are situations where I would choose to do that.  I have seen cases where multiple vis stacked on top of each other made perfect sense.  I don't remember exactly what it was but I think it had to do with the error wire when saving a vi to a previous version.

"A more equivalent example would be if VS allowed you to change the font color of some of the code to white on a white background."

Bad choice.  VS *does* allow you to do that.

Black text:

White text:

[tst]

> While I appreciate the difficulty in debugging extensive hidden code, choosing whether or not to implement hidden code is purely a style decision...

Oh, my problems were not with extensive hidden code but with the small buggers and it was never a style decision. It's usually a bug caused by someone (or LV) accidentally hiding code. I found it very amusing recently when someone who was clearly against the suggested implementation was bit by the exact same problem and was annoyed enough to suggest another solution to the problem - http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Structures-should-not-be-allowed-to-hide-code-in-diagr...

I also find it amusing that this thing that so many people are unhappy with has spilled into quite a few separate threads by now (I count 6 off the top of my head, as well as some private messages). Clearly there is a problem (or at least a potential problem, because in practice it doesn't happen that often).

> I have seen cases where multiple vis stacked on top of each other made perfect sense.  I don't remember exactly what it was but I think it had to do with the error wire when saving a vi to a previous version.

You're probably talking about the case where you upgrade or downgrade a VI and LV adds another VI on top of it to account for the missing functionality. I don't think it makes perferct sense. I understand the design decision, but I think the result is a necessary evil, not something desirable.

> Bad choice.  VS *does* allow you to do that.

OK, since AQ isn't here, do *you* think that's a good idea? Also, note that I said *some* of the code. Once it's all of the code, it's fairly obvious that this is what you've done.

Edit - And to clarify, by "some" I meant "an entire section, including all control words, class names, comments, etc.".

[Darin.K]

As the person clearly against this idea, let me say that my enforcement mechanism is disallowing the behavior, not breaking code.  I think the drawing should be kept separate from the grammar of the language.  

As to the VS example:  The font color has no bearing on whether the code will compile.  If I try to compile code with white font on white background I do not expect a compilation error.  Same if I change to Dingbats font.  This analogy breaks down in regard to my idea as well, and here as well.  In order to hide the code in VS I have to go in and change the color deliberately and with bad intentions.  That is a me problem.  The LV IDE will, on the other hand, do things like spew terminals all over and give you no clear indication which structures have autogrow on or off.  That is not a me problem.

Part of this is an fundamental LV flaw, or a fundamental LV feature depending on your perspective.  Things that should be IDE choices IMO (terminal/icon view, autogrow on/off, grid layouts) end up being tied to individual items or individual VIs.  When I open a c++ file, the font and color are how I specify them, not how the previous developer did.  I may turn autogrow on everywhere, but someone else does not.  Code elements merge, and now you have some weird mixture on your BD without and indication which is which.

[Daklu]

I found it very amusing recently...

That thread is what led me to this one, and imo both ideas suffer from the same thing.  (Hence my posts on both threads mirror each other to a large extent.)  They are too heavy-handed.  Not only are you cutting off a toe to treat a hangnail, but you're cutting off *everybody's* toe to prevent them from ever getting a hangnail.

Oh, my problems were not with extensive hidden code but with the small buggers and it was never a style decision.  It's usually a bug caused by someone (or LV) accidentally hiding code.

Your intent is to prevent bugs, but your solution is to impose a specific style on everybody.  Why do I say that?  Code that is visible compiles to the exact same DFIR as the code hidden behind a structure.  By definition, any decisions that do not affect the compiled output is style.

Clearly there is a problem (or at least a potential problem, because in practice it doesn't happen that often).

I agree in practice it doesn't happen that often.  I believe people think it's a problem far more than it actually is a problem.  I started using LV in 2006 and I can't remember the last time I actually had a problem with hidden code.

...do *you* think [setting text color to match the background is] a good idea?

Oh heck no, at least not in any common coding situation.  But I think not allowing someone to do that if they want to is an even worse idea.  The IDE is a tool.  Let the users decide how to use it in a way that meets their needs.

Also, note that I said *some* of the code. Once it's all of the code, it's fairly obvious that this is what you've done.

I could hide some of the code by making the #region directive font match the background color and collapse it.

And to clarify, by "some" I meant "an entire section, including all control words, class names, comments, etc."

Visual Studio allows you to set custom colors for control words, class names, comments, etc. independently.  I could have changed them all but didn't want to have to remember what they all were when I changed them back.  Regardless, that part of my post was intended only as a humorous illustration that your analogy doesn't support your idea.  I don't think there's any value in arguing about the strength of analogies (or using analogies to justify a particular course of action.)

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

The LV IDE will, on the other hand, do things like spew terminals all over...

I wholeheartedly agree that having LV spew terminals all over the block diagram is an issue, especially in those cases where it hides them.  The solution is to fix the placement mechanism or provide other means to get to those elements (perhaps scrollbars?), not prevent any code from ever being there in the first place.