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]

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.

You're going to love this next one - code is never buggy. The code does exactly what you tell it to. A bug is always related to user expectation and that has nothing to with the DFIR graph. It is controlled only by what the user sees on the diagram, so by definition, bugs exist only in the user domain and resolving a bug is always about changing what the user sees, not about the compiled code. The recompiled code is only the tool used to deploy that change.

I started using LV in 2006 and I can't remember the last time I actually had a problem with hidden code.

I don't remember specifically either, but the last incident that definitely comes to mind is from the last couple of years. My point about it not being a style choice was that the creation of the hidden code was always unintended, and I can say that the effort to find the problem was always not minimal.

Visual Studio allows you to set custom colors for ... I don't think there's any value in arguing about the strength of analogies

Well, the fact that VS allows it is certainly not an indication that it's a good thing, but in VS it has to be a desicion made by the user and it's global. In LV, you can do it accidentally. But you're right about analogies, and luckily there's no need to argue about them, because we already did that in one of the other threads when an analogy was made to washing dishes and the analogy broke fairly quickly after being modified to fit the actual discussion. 😉

[Daklu]

(The joys of web-based editing...)

You're going to love this next one - code is never buggy.

I've heard that before and understand the perspective, but personally I don't subscribe to it.  It all comes down to how you define "bug."  In my lingo, a bug exists when the code's actual behavior doesn't match the developer's intended behavior.  In other words, if the code doesn't do what I--as the person implementing it--says it does, then there's a bug.  If it does do what I said it will do, there's no bug.  I may not have implemented what the customer wanted me to implement, but that's a "defect," not a bug.

("Bug" implies the problem exists, and must be fixed, in the code.  "Defect" is a more general term to indicate a mismatch between customer expectations and actual functionality.  It can be fixed by changing code or by changing customer expectations.)

My point about it not being a style choice was that the creation of the hidden code was always unintended, and I can say that the effort to find the problem was always not minimal.

I agree sometimes it takes a lot of effort to find the hidden code.  I think a better solution is to give us tools to make it easier to find hidden code, not remove the possibility of hidden code even existing.  Trying to eliminate all the stupid things developers can do is an exercise in futility.  It doesn't matter how idiot-proof NI makes Labview, there will always be a better idiot to discover new ways of making life difficult for experienced developers.  Odds are he will be working with you.

[tst]

> I think a better solution is to give us tools to make it easier to find hidden code

I think the current tools (VIAN and the warnings list) are reasonable in their functionality (although the list is usually flooded with other stuff). The point is not so much about the tools for finding it, but about knowing that you need to find it. If someone tells me "the code doesn't do what I expect", then "hidden code" is NOT the first thing I think about.

The "add an indication" idea covers drawing attention to the hidden code reasonably well, but I didn't like it mainly because it requires much more changes and new idioms, as opposed to the relative simplicity of "don't allow" or the absolute simplicity of "break".

[LabBEAN]

Would it make sense to make this (i.e. breaking a VI when it contains hidden code) an environment option that would default to the current behavior?  You have my vote.

---

Daklu wrote:

It doesn't matter how idiot-proof NI makes Labview

---

Thank you for offering opposing perspectives!  Help us spread the correct written representation of the graphical language we all adore.  (It's an acronym.)

[tst]

> Would it make sense to make this (i.e. breaking a VI when it contains hidden code) an environment option that would default to the current behavior?

That's a possibility, but not an ideal one. Even in simpler things, but certainly in something like this, it would be ideal if you know exactly how LV is going to behave when you approach it. Now, if you normally work on only one computer, then you would be fine, but as soon as you're asked to do something on another machine, you would have no idea how things actually behave. The cloud-based config suggested elsewhere could help with that, but only on networked machines.

[LabBEAN]

Is code considered hidden if it's partially blocked by a comment, structure, or node?  I would think so.  If LabVIEW 2014 broke hidden code without an option to revert to the previous behavior, then many VIs would break.  There is no telling how much time we would all spend refactoring working code.  Even if I agreed with this approach (and I like straightening other people's wires, so I'm sympathetic), there is no way NI would accept this kind of support / reputation risk.  If there were an option to revert to the current behavior but the default were to break code, then you have the worst of both worlds:  (1) rhetorical question:  would folks figure out how to revert back ahead of calling NI / griping to their colleagues about LabVIEW? and (2) tst wrote:  "as soon as you're asked to do something on another machine, you would have no idea how things actually behave".

There are things that we all do when we bring up a new environment or switch to another (e.g. customer) machine.  Allowing this to be configurable just means we add another line to our custom LabVIEW INI files.  If NI sets Break VI with Hidden Code = FALSE by default, they don't get support calls and we have the option of turning it on (even if momentarily to spot check for hidden code) or off if we find the issue and don't want to tidy up the entire code base.

I can't remember if anyone mentioned it, but I presume that LabVIEW would not break VIs with locked diagrams.

All that said, I sort of like having LabVIEW prohibit folks from actively hiding new code.  I guess there could be an exception for running wires behind structures so there's not mutiny in the community (although it always bugs me when I have to work on code where someone did that).

[LabBEAN]

One more thought:  I could see this being helpful to be set on a per-VI basis (even temporarily) via the LabVIEW project.  Sort of like the "Mark Project VIs to Separate Compiled Code" dialog, only I wouldn't want the setting to travel with the VI.  I haven't thought through how the two settings (environment and project) might work together, but I could see applications where you know a part of the code base is solid and want to exclude all those messages from the error dialog.

[tst]

I did refer to the backward compatibility issue earlier in the thread by saying this:

---

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

---

The problem is that I don't think that having it as an option or applied to only some of the code would be practical, because if you don't know it's applied to everything, it might as well be applied to nothing. Likewise, temporary toggles are not needed, as we basically already have that - turn on the warnings display and you will see it (or run the VI analyzer test). The point of the idea is precisely that you don't have to explicitly look for these, just like you don't have to explicitly look for add primitives with unwired inputs. If you have to ask to look for these, you already lost.

Unfortunately, I think that it would practically have to be an all-or-nothing deal (and currently it looks like it's strongly on the nothing side and liable to stay there).

[LabBEAN]

As others have mentioned, there are too many warnings which is why most of us leave them off.  If this idea were implemented as configurable, then I for one would turn it on, especially if I could train the environment to ignore some repeat offenders (e.g. option to add comma delimited list of namespaced VIs to ignore to LabVIEW.ini).  So, I still see the idea + option to turn it off as a vast improvement over the current implementation.

If folks protest and somehow win the argument to allow the practice of actively hiding new code, the other side of the idea could be implemented as an option as well but could default to ON:  Break VI with Newly Hidden Code = TRUE

[InfiniteNothing]

Hey, I found this idea which might be a good way to solve this problem:

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Run-VI-Analyzer-checks-as-part-of-development-compilat...

Basically, we bring VI analyzer findings to the front of the block diagram. Like VI analyzer, the developer could deselect any issues they don't care about.