Reference Inputs Default to Required

[Hooovahh]

This idea is for improving the connector pane to default to required inputs for terminals that use reference type data.  So if I have a new blank subVI and I wire a VI reference to an input, this should be set to Required by default.  I'd also suggest this be the same for a Create SubVI from selection.  Obviously you could change it from required, because the developer may have some code in the VI to detect an invalid reference and do something specific.  But in most cases if I do something like wire a Queue reference to an input, that input should be required.

One could make the argument that this idea could be done today, by making all inputs default to required, which I think goes too far.  Many times I have code that detects unwired inputs (by looking at the default value for the control) and it shouldn't make an input required if it isn't really required.  What I mean is in my work flow the majority of inputs should be recommended, but the majority of references (Queues, DVRs, Control References, VI References) should be required.  There are a few data types like Classes that could be reference based or not, and I could see an argument for this being required, or recommended, and for these I don't really care how they behave.  But for inputs that are clearly reference based I think it would help from making code that the developer mistakenly leaves recommended.

This could be an INI key in LabVIEW for those that don't want it, or for those that choose to make all inputs required.

[Darren]

I've found that 'make all terminals required' fits my workflow nicely. Most VIs I work on are internal VIs, and most internal VIs need all their inputs wired. I'm fine changing the occasional non-required input to 'recommended' when the situation occasionally comes up, maybe for about 5% of my subVI terminals.

Before we had 'make all terminals required', I would always forget to wire new subVI inputs after creating them, and many times, those inputs were not reference types.

[AristosQueue (NI)]

 >which I think goes too far. 

Please try it. I almost guarantee that your error rate during development will drop SUBSTANTIALLY. I can't promise that ... your OCD level may be sufficiently high that you never leave things accidentally unwired... but for most people, it helps a LOT, in my observation. I believe this will apply even in code with a lot of "let them use the default values"... those terminals are almost certainly less common than you think they are once you start looking at subVIs and not just your top-level APIs at module boundaries.

As a point of comparison, every other programming language that I know of assumes all parameters are required UNLESS explicitly labeled otherwise. LabVIEW is the only weird one in this way, and I very much believe we do a disservice to users with the current behavior.

[Hooovahh]

I appreciate (and expected) your opinions.  But based on my evaluation of our internal reuse library, which has every terminal individually evaluated, and based on the evaluation of the palettes shipped with LabVIEW, I'd say the majority of the time a terminal is not required.  A well written API should know what the common uses of the function are, and can use default values in these common cases.  I'm not saying every subVI should require no inputs, I'm just saying that as a developer a well written API makes writing code easier.

I won't lie and say I've never made a subVI and forgotten to wire a terminal, because it was recommended, but it certainly isn't often.  I'd say maybe a couple of times a year, and I generally do LabVIEW 40 hours a week.

[AristosQueue (NI)]

Hooovahh: You are an interesting data point and one I will keep in mind in the future, but you are definitely the minority of LV users I have talked to over the last five years.

[AnthonyDeVries]

Maybe you could make it user definable ?    Then you could fit everyones style and typical workflow.

The OP indicates that having all terminals default to required goes a bit too far. How about adding an exception list?

I think it can be a short list of typical inputs that user might not want to be default required.

We would have to brainstorm a bit what would go on that list.

References obviously should be on the list of exceptions, as the OP is asking for it. 

I think the error-in would also be a candiate. 

Actually, the list doesn't even have to be totally based on type...   You could even do things like having all left-side terminals default required, and top/bottom recommended.