Code Reuse: SubVIs that process arrays vs SubVIs inside For Loop?

[DoctorAutomatic]

Is there a consensus on whether it is best (for reusability) to make SubVIs operate on an array input vs a SubVI that operates on the element data type and then wrapped in a For Loop in the calling VI?

If one went with a SubVI that operates on an array but only had one element to process in a particular scenario, the incoming wire could of course be passed through a single node build array function.

Obviously the result is basically the same but since I'm not a formally trained/educated computer sci/software engineer I'm curious if there's an established rule of thumb on this due to some aspect I'm not aware of or considering.

My first instinct (as in, without giving much thought) was/is to operate on an array (if that is the scenario I find myself when first creating a SubVI), if for no other reason than I don't have to use up space in the calling VI to accommodate a for loop. However, lately I've been thinking this is wrong, and that making SubVIs as "low level" or agnostic as possible should drive the preference for operating on just the data type of a single element and wrap the SubVI call in a for loop.

Make sense?

[crossrulz]

As with everything in engineering, "it depends".  I also tend to make the subVI act on the array.  But I have some libraries I am currently developing that I operate on the single element and the calling VI supplies the FOR loop.  I am doing it this way because there is a good chance I will want to, as a user, use the single element version.

[Mark_Yedinak]

What I have done in the past is to actually create both subVIs. and expose them to the user. The single elment VI can be called directly. The array variant of the subVI simply has the loop internally and it calls the single element variant in the loop. I will mention that I tend to write most of my code as reusable which is why I provide both methods.

Ultimately, the answer is "it depends".

[Gregory]

This is a great discussion to have. There is also the user interface to consider if you do some very time consuming loading or processing in a loop and want to let the user know that something is going on (and maybe give the option to cancel). I have a simple "progress bar" VI that I can drop into longer running loops that becomes a popup when the loop is running. But, if you wanted that information to be displayed on your main front panel then you would need your loop in the main block diagram or you could add some data transfer mechanism to get the data out. 

[cbutcher]

I would imagine, without any real evidence, that if you have a (particularly small?) VI that can operate on a large array or single elements, you might have a faster processing time using the Array input/output version and avoiding the subVI call repeatedly (unless you inline).

If these conditions (large array, minimal processing in subVI) aren't true, this becomes less likely to be any sort of concern.

[altenbach]

Operating on arrays often doesn't require a FOR loop, in fact the array and scalar code variants can have almost identical code. So wrap it all into a malleable VIM and don't worry. (Assuming you have a very recent LabVIEW version, of course.)