"Function terminal not connected" detection (plus shameless plug for another pet-peeve of mine)

[X.]

Must have been discussed a zillion times, but just in case, there it goes:

what's wrong with this picture?

apparently nothing. If I grab the function and move it:

Note that LV must have "computed" something here to reroute the wires, etc.

But wait, what happens if I grab the wire and move it?

Oops! I did not connect the output of the function to the indicator. Instead, I inadvertently connected the input.

Needless to say, this is a F-ing nightmare to debug... unless you think of verifying that the value before the function and after the function actually gets incremented. Which you will, eventually, but not until after having wasted a lot of time thinking of all other possibilities elsewhere in the code.

Bottom line (this is only an example I just encountered for the umpteenth time a minute ago), LV does not provide much in terms of warning for this kind of potentially very damaging error. This is very much related to the discussion I started here with very limited success (man, am I an upbeat person!). 

Suggestion: not only allow to define VI outputs as REQUIRED but also add warnings when a function that has its only or most important output(s) unconnected.

And if not everybody is interested in this kind of sanity check (I am talking about functions), you could offer this "warning" as an option (in a warning definition panel in the Preferences).

[User002]

A more "gentle approach" would be something like a coercion dot on the nonconnected terminal.

[Mr.Mike]

What if this were a VI Analyzer test?  Would that be OK?

[dthor]

I'm personally fond of Bleach Dead Code by Altenbach.

Which means I would consider this a duplicate. I don't think that outputs should be required - I think it would make prototyping code much more annoying.

[SteveChandler]

I don't like the idea of required connections on outputs. I want to be able to run code that is still in development. Required inputs are a different story, the function needs them in order to execute so it makes sense that the VI is broken.

I also like the Bleach Dead Code idea. I would take it further and have an option to delete dead code.

[Wart]

I'd like to see things like this show up as warnings in the error list.

[X.]

VI Analyzer is not part of the base package, I think. But why not.

I agree that the bleach dead code idea is similar (see Example 1 discussed later in that thread), but I am afraid it will not cover cases where the problem is hidden in, say, a case structure (or subVI for that matter). It requires an active visual inspection of the code. That's why I would prefer a warning option. I have added a link to this suggestion there, just in case NI is watching the other one. Please think of this as weakness of graphical programming over text-based programming that requires an efficient safeguard.

[SteveChandler]

Kudos for the general idea, but not for required outputs. That just doesn't sit well with me for some reason.

[X.]

I am not sure I understand why people are OK with required inputs but not outputs. Is this something coming from text-based languages? I don't recall having "required" inputs to C-function calls that would break a compilation if improperly passed. I mean of course you need to pass a parameter, but if it is by pointer and this pointer is invalid, you'll crash your program while your compilation will (of course) have not generated any warning. If anything, I would expect the compiler to complain that a pointer to a structure has not been defined in the function, if the function itself is returning said pointer. That's of course not exactly the same as requiring that this structure be used for something by the calling routine, but the whole idea of G is to allow doing more (or something different) than with a text language.

Recommending that an important piece of information be examined seems to me an added benefit. Especially if you think of a case of a mistaken connection as I illustrated above for a function: think of a VI returning A and B, and for whatever reason, you connect A twice (while thinking you are using B the second time). This is once again a debugging nightmare, because chances are you will never think of checking that you use the same wire twice...

Preaching in the desert am I...

[AristosQueue (NI)]

I agree with X here. To extend his C analogy, it is the equivalent of a function that takes a pointer as input because it is going to modify it and you don't give it *any* pointer. That's how outputs work in those languages, and an "unwired output" is a missing parameter. Marking them as "required" would be the default in all the text languages -- you have to do special syntax to give those parameters default values (like NULL).

[JÞB]

Mr. Mike.  Not only is having it as a vi analizer test a GREAT IDEA its SO good that the "Dead Code test" already finds this wiring error.  I'm happy with the current test and use it to prevent this bug allready.