SubVI/ project organization best practices?

[dp2016]

Hello All,

I have several test stands that operate off two very similar (base) programs. They each share most of the same subVI's. I have 3 total individual projects that share these subVI's but the way I have it right now is these subVI's are their own entity in each project, so when I want to make a change, I have to do it to all three.This is obviously not ideal.

My first thought is to place all the shared subVI's into a single folder and have the individual projects look at this folder but I was curious how the great labview gurus would handle a problem like this? (combining the base programs would not be a simple task as the hardware is quite different)

any input is welcome,

Thanks in advance

[JÞB]

What you are talking about is a common re-use library.  These are absolutely invaluable however there are some common pitfalls that you need to address before you "Just move stuff to a common folder."  I'll give you some advice learned the hard way.

1. You must have a SCC system.  Period, don't even think about using "Common" components without one!  You are much better off having multiple copies and making the same changes twice.
2. Maintain the reuse library by LabVIEW Version and don't let developers mix-n-match versions in development. 
3. Package your reuse components in a distribution package (VIPM works really well here and CAN provide a mediation for maintaining multiple LV Versions of the source except when actually using new features.
4. Make libraries for related components (lvlib) and include Unit Tests and documentation on the project for each lvlib.  Oh,Yes! Reuse code is "Sacred" any change to that code needs to be justified and it ins and outs need to be locked down!  You, May encounter improvements that could be made to re-use components.  As an example: I once wrote a silly API for interfacing with an external <Gidget> resource, Unit tests ran great!  Wound up 6mos later finding an edge case where I had passed a reference and an auto-indexed array to a for loop without putting the reference on a SR.! (Silly me, the reference goes bad if the array is empty breaking downstream code) Changed documentation adding a requirement, added a unit test, submitted to peer review and fixed the bug.  Don't go off "cowboy coding" when changing reuse modules.
5. Lastly, Templates.  Use vits to keep reuse components consistent in look and documentation, use Icon Templates to keep related vis looking like they belong together, use Project Templates to keep your lvlibs consistent in organization and documentation.

Mostly though, Documentation, Documentation, Documentation!!! Before you code, while you code and after the code review!  Reuse code needs tight control.

[Jacobson-ni]

Where exactly do you keep your unit tests? Are they in the same library as your reuse code or do you have them in a separate library right next to it? Also, when you install the package do you include the unit tests or should they just live in your SCC?

[JÞB]

Hey Matt.  I usually keep the UTs in a tests folder in the source lvproj of the lvlib.  Which reminds me I need to post a report about New••Unit Test from PE naming everything Unit Test with no prompt to rename the file  I recommend a document folder too!  Test reports go in the lvproj as well as a readme bug tracker.  A link to fogbugs would work too to trace defects in the project.  A common rel path makes it simple to run  UTs programmatically with an easy to understand utilliy.  UTs reports documtation do not deploy with the reuse package.

  Its Fairly robust for small to mid sized teams.  I'd not mind an overview of how NI manages huge teams around new dev and defect investigation.  But that is way beyond scope for the OP.