Organize Library Member VIs in the Project, Not on Disk

[Darren]

One of the many benefits of using libraries in LabVIEW is the ability to organize code. You can create virtual folders within your library, apply scoping to those folders, sort them by name or logical grouping... the list goes on.

And since we have the ability to organize library member VIs within the library, there is no reason to also create any sort of organizational hierarchy for library member VIs on disk. If you start creating subfolders on disk for library member VIs, you've now got two places to organize, which will very likely become out-of-sync, leading to more confusion than utility.

Follow these two simple rules for library management on disk:

1. Create a folder that contains the .lvlib and all its member VIs in a flat list.

2. If your library contains sublibraries, each sublibrary gets its own subfolder within the owning library folder containing the sublibrary .lvlib and all its member VIs in a flat list.

Another big reason to avoid unnecessary disk organization for library member VIs: the high likelihood that you will break something if you're using a framework like DQMH or Actor Framework. These tools often assume a particular organization for source files (that the tools themselves created), and when you start moving stuff around on disk, you'll likely break these assumptions, and in doing so, break the scripting tools that make these frameworks so useful in the first place. (Also, as a general rule, you probably shouldn't move around framework-level boilerplate code within the .lvlib organization either.)

tl;dr - Use a flat folder structure for libraries and their member VIs. Only create subfolders to hold sublibraries and their member VIs.

[SteenSchmidt]

This I don’t completely agree with 🙂

Yes, you shouldn’t attempt to keep a folder structure reflected 1:1 in your library. But one folder with all files is not taking advantage of what folders are for: To organize and group your files in a semantic hierarchy. Why would DQMH and NI AF require a particular folder structure for instance, instead of just one folder with all their code in?

I prefer to group by functionality on disk, so all code files that has to do with “Sort” for example, is in the “Array/Sort/“ folder.

Then in the library it may or may not be a similar structure. But maintaining the “Sort” functionality is way easier when they are together on disk in a folder, rather than intermingled with 200 other files in one folder 🤷🏼‍♂️

[Darren]

---

@SteenSchmidt wrote:

what folders are for: To organize and group your files in a semantic hierarchy.

Folders are for holding files. Libraries are for organizing and grouping your files in a semantic hierarchy.

But we can agree to disagree. 🙂

---

@SteenSchmidt wrote:

Why would DQMH and NI AF require a particular folder structure for instance, instead of just one folder with all their code in?

---

That's just it... these frameworks assume a structure that they created (usually flat on disk, and usually organized in a certain way in the project), and their scripting tools can have problems when people move stuff around.

[SteenSchmidt]

---

@Darren wrote:

---

@SteenSchmidt wrote:

what folders are for: To organize and group your files in a semantic hierarchy.

Folders are for holding files. Libraries are for organizing and grouping your files in a semantic hierarchy.

But we can agree to disagree. 🙂

---

@SteenSchmidt wrote:

Why would DQMH and NI AF require a particular folder structure for instance, instead of just one folder with all their code in?

---

That's just it... these frameworks assume a structure that they created (usually flat on disk, and usually organized in a certain way in the project), and their scripting tools can have problems when people move stuff around.

---

No, I mean, they require a folder structure for a reason. They couldn’t make do with one flat folder structure. Neither can I when managing my code in the file explorer.

The problem doesn’t come from a folder hierarchy, but from trying to keep the library organization in sync with the folder hierarchy. Those two are different views of the same source. Same could be argued about why would you make any kind of organization in your library? The LabVIEW palette is your public API, you could make your hierarchy there only.

Organization serves different purposes in the different representations of the source (folder, library, palette). But they all benefit from organization, because humans interact with them at some point or another. And humans need their stuff grouped and labeled to easily figure out what is what.

[cbutcher]

Are classes are considered in the same grouping as your point 2? Or do you exclude this on the basis of keeping any inherited/ing classes in separate libraries?

Having too much depth in directory hierarchy can also lead to problems building (particularly for Linux-RT code, where some of the available path length is consumed by extra elements for the build target), but some degree of disk-based folder organisation hasn't typically been a problem for me.

[Darren]

---

@cbutcher wrote:

Are classes are considered in the same grouping as your point 2?

---

My rules are for library membership, not class relationships. I don't think child class folders should be inside parent class folders. 

[cbutcher]

Sorry, I obviously failed to show what I meant. I was asking if you would create a new folder for each class (as if it were a sub library) or if those didn't fit your rule 2, and you'd instead have multiple classes in the same directory.

Once you have an inherited VI, you'll of course need some disk structure to avoid overwriting, but my second part was asking if you avoided this by just having one class per library in that case (so the class and it's VIs would still just all be in the same folder as the lvlib file).

[Neil.Pate]

I am pretty sure he means one directory per library/class.

Mixing multiple classes or libraries inside the same directory is a recipe for disaster I think.

[Neil.Pate]

This one I agree with 🙂

But I really avoid putting libraries inside libraries...

[joerg.hampel]

For the record, I don't agree with this recommendation, either. In my opinion, it makes perfect sense while working in the IDE (i.e. doing the programming) but does not take into account managing resources in SCC.

At HSE we have a rule of storing all manually created VIs for a DQMH module in a subfolder on disk, independently of where they are stored inside the library. This makes it much easier to understand the nature of resources while outside the IDE.