VIs, VIs everywhere but not a lot inside.

[Taylorh140]

So I really like the LabVIEW classes, but always end up with alot of vi's that do very little. I was curious what people do about it?

 

 

[Taylorh140]

If you use a strategy not on the poll would you elaborate?  I would appreciate it. 

[Gribo]

Re-use libraries whenever it is possible. I rather not reinvent the wheel. As for unused code, VI analyzer will find that. If a project has a Sub VI with no callers, I remove it from the project.

[LogMAN]

My system is to put them in project libraries or classes and change the scope to private if possible. Anything private that only serves as a wrapper can then easily be replaced by its content (for example, private accessors that only bundle/unbundle the private data cluster). Classes that expose all elements of their private data cluster can also be refactored into project libraries with simple clusters, which gets rid of all the accessors.

Last but not least, VI Analyzer and the 'Find Items with No Callers' option are very useful to detect unused and dead code. Especially after refactoring.

On 1/21/2022 at 5:22 PM, Taylorh140 said:

So I really like the LabVIEW classes, but always end up with alot of vi's that do very little.

What do you mean by "very little"?

The 'Add' function does very little but it is very useful. If you have lots of VIs like that, your code should be very readable no matter the number of VIs.

[thols]

Number of VIs means nothing. Design and following SOLID principles is everything. Then you will never have too many or too few VIs or have a hard time finding "the code".

[Bryan]

In my current role, I've inherited a LOT of bad code with who-knows-what inside.  This usually ends up in complete refactoring of the code wherever possible and removing unused VIs, unless they're part of a library or collection of VIs that are or could be relevant to the application in the future.  

VIs that are obviously reference/example/testbeds, I will leave in for future reference.  

We keep all of our code in SCC, so if we remove VIs that we consider to be unused/junk, they're never really permanently deleted.  If the application is not in SCC, we add it in it's current state as a "snapshot" so that we can always revert or retrieve VIs if they end up being needed later.

[hooovahh]

For the second question I said other.  What I wanted to say is there is very little if any, unused code in the project.  If I make a VI to do some purpose, and then that VI is superseded, or the functionality is replaced, I delete the VI from the project and SCC.  Obviously it is still in the revision history so it can be restored.  There are a few cases when a VI isn't used, but still valuable, and in those cases I'll either move it to a sandbox folder for the project, or copy it to the reuse library candidates, where it might be polished and added to a reuse library.

With classes I might end up with several small VIs that don't do much, but accessor like VIs are usually scripted through the class as needed and don't take much effort to make.  And for me almost all of my classes belong to reuse libraries, where you'll access them from the palette anyway.  So it might have unused VIs, but it isn't like you are aware of them in the project, or where they might be on disk.

[Rolf Kalbermatter]

My projects usually have one or two folders called Tests and Junk. Tests are VIs that I create to test certain functionality. For instance in a recent project I created a number of test VIs for various subVIs that I used in an FPGA program. These are typically not real tests in the sense of Unit Tests but more a test bed to easily run the VIs interactively and test functionality and improvements as well as behaviour of the various functions. Junk I put VIs in that I sometimes create for a quick and dirty test of some function, occasionally also VIs that I might create for helping in a forum post while waiting for the FPGA compiler or some tests to finish.

Outside of these two folders there is usually almost never any unused VI. I make a point to regularly check for VIs that are not anymore used and to simply delete them (or sometimes move them into the Junk if I think there might be some future possibility that it is needed again), but most are left overs from earlier attempts of reworked VIs that are now used in the program, so they can safely go away.

And of course everything gets regularly checked into Version Control, with some more or less useful commit message. 😀