Everything in your project besides the top-level VIs can be classified as “support” or a subVI. That doesn’t mean that support should be a dumping ground for everything in the project that is not a top-level VI. Each component of the app should be thought of as a distinct, cohesive group independent of other components. Using support/subVIs causes confusion for you and for others about where VIs should go and how you should group them. It also adds one more unnecessary layer to your folder structure that makes it just that much slower to navigate.
This one may or may not be a bad practice depending on how it is used. If this is a bucket for all globals, then it’s wrong (see note above about organizing files by type). If you use this as a place for application-wide globals (truly global scope), then that is much better. In the latter case, the folder should probably be named something better, like “Application Globals”. Globals that share data from a component to other components are part of that component’s interface and should be grouped with the owning component (cohesion).
These VIs may have loosely similar behaviors (they are loops/processes/actors/etc.), but they belong to different components and should be grouped with those.
Again, VIs in this case are being grouped by general behavior (they are in fact loops), but they should be separated. Remember the read/write example?
A Better Alternative
This particular project already has a high degree of coupling, and may be a result of thinking about organization in the wrong way (or not at all). A better way to think about organizing this project would be something like this:
Moving the files does not change the fact that this source code is still highly coupled, but this organization by components will provide a much better project structure. If each component is thought of as independent with a defined interface for other components to use, it will lead to a high cohesion/low coupling design.
So you have seen some of the bad practices for project organization and why they can have a negative effect on code. Join us for the next installment, where we will discuss what some better practices are for organization as well as some naming guidelines. All these considerations are part of a holistic approach to software development that results in better, easier-to-maintain code. If you’re looking for help with your LabVIEW-based system, check out our LabVIEW expertise and reach out if you want to chat.
If you’re interested in organization and naming for LabVIEW projects, check out this article.
Deep into learning mode? Check out How to deal with LabVIEW Spaghetti Code.