The Case For Virtual Folders

I had a recent issue come up and I'm curious to get others' opinions. The issue revolves around folder hierarchies on disk with lvlib and lvclass files. I had always been taught to use a flat folder structure and organize my VIs in the project window using virtual folders. On disk I would just have a flat folder structure on disk for the class or library file and all its VIs without any other disk folders. The only exception was if a library contained a class, then that class would have its own folder on disk inside the library folder. Until recently I never really thought much about why, I just knew that was what I was taught and what most people do. I'd seen a few people use a folder structure on disk and didn't really think much of it. I thought maybe they were self-taught and didn't know any better or something similar.

I have a consulting gig where I just meet with a team of developers a couple times a week and answer questions, help them troubleshoot problems, review code, and provide general guidance. They asked me to review a template they were working on. I made a bunch of notes. One of the things I noted was that they used disk folders to organize their library contents. I mentioned that I only use virtual folders. I made it a note that was probably just my personal preference and that it was something they should consider. They asked me to clarify.

Why Virtual Folders?

In some ways I'm glad my client asked this question because it has helped me clarify my thinking around this. Previously if someone had asked me I probably would have just said "Well because that is what I was taught and it appears to be the standard so why not?" My client pushed back a little on that so I had to dig deeper and come up with a better reason.

Private/Public Folders

The first reason that I've heard others use to support virtual folders that I gravitated towards was the ability to have just public and private virtual folders. Rather than right clicking on individual methods and making them public/private you could do it at the folder level and then just drag/drop VIs around. That's a nice trick. However I'm not sure that precludes using disk folders to organize files in Windows Explorer.

Linking Issues

The real issue against using folders on disk has to do with linking. If you move a method from one virtual folder to another, it does not affect the calling VI at all (assuming access scope doesn't change). So you can reorganize as much as you want. Since I am a big fan of TDD and agile development, I end up doing this a lot.

Moving VIs on disk though, does affect any calling VIs because they are linked by path. So reorganizing VIs on disk is a pain. You have do it from within the LabVIEW files tab in the project and you have to have all callers in your project in order for the links to be updated correctly. If a caller is not in your project, it will still link to the old location on disk.

This is actually the real deal-breaker for me. I want to be able to reorganize my VIs inside a library or class without worrying about all the callers.

Synchronization issues

The other issue is with synchronization. You can't have autopopulating folders inside a library. LabVIEW doesn't allow it. So if you create this elaborate hierarchy on disk, when you open the library in LabVIEW, you will just have a flat hierarchy unless you manually recreate the virtual folder structure. If you move a VI on disk you'll have to then manually sync the virtual folders. The virtual folder structure can easily became out of sync with the folder structure on disk. It is difficult to detect this and it can be misleading.

The opposing argument

The opposing argument was that the client liked seeing the VIs organized in Windows Explorer. I don't typically manipulate files in Windows Explorer so that argument doesn't carry a lot of weight with me. The client uses Tortoise Git (which I haven't used in years). It integrates with Windows Explorer, so they were spending a lot of time there. Perhaps that explains the difference a little. It was also template code, so they weren't counting on doing a lot of refactoring to the structure and folder layout. They wanted it to be standard across all the implementations of this template. I'm probably doing the client a disservice because there were probably others reason they preferred disk organization and this appeared to be the main one.

Resolution

In the end that argument for organization on disk won out for them and they chose to continue using folders on disk to organize VIs in libraries. I decided it wasn't really a battle worth fighting and ultimately it was their decision. It still left me wondering what others do? Surely my clients aren't the only ones who've made this decision. I've seen others do it.

Which do you use and why?

I'm curious to hear others' opinions - which method of organization do you use and why? What do you see as the pros and cons? Add your opinion in the comments.