Library Folder Structure

 Greetings LabVIEW nerds,


It's been a while! I've been busy.


You see, recently I've been working on a re-use library that has the potential to be used by any LabVIEW developer within the organisation who is in a manufacture or test role - in fact, it could be included in every jig. So considering the number of people who might use it, it's worth taking the time to make it nice and developer-friendly. I've spent many hours writing the documentation, unit tests, examples, etc. Even to the point that I did a re-write to remove all dependences. (I hadn't realised that different versions of OpenG would cause headaches for people, oops.)


Something that I sought advice on was my folder structure for my library. I had always been on team 'Project Explorer structure mirrors the disk', but when it came to where my Unit Tests, VI Tree, Examples etc. lived, I couldn't make my mind up. And moving them around isn't an easy task.


Top tip: You can click on a folder in the Project Explorer (Files View), and 'move on disk' and it will sort out all of the dependences for you. If you want to move individual files, then instead Save As > Rename.

Moving a folder on disk in the Project Explorer


One of the wise CLAs that I work with suggested bunging ALL the module code into a flat folder for the module, and then using only the Project Explorer to create a structure. It makes it much easier to switch VIs from public to private, for example - you only need to change it in the Project Explorer. I've come to really like this approach.


The Project Explorer structure I came up with in the end was

  • Module Library.lvlib
    • Public
      • API
        • ctl
        • vi
        • Module API (poly).vi 
    • Private
      • Examples
        • VI Tree.vi
      • Unit Tests
      • Sourcecode
        • ctl
        • vi

And the Module Tester outside the library in its own folder, à la DQMH. Folders for Data, Documentation etc., were also placed outside the library. It would be nice if we could standardise on something like this internally to make sure projects don't become a bit of a jumble.


Do you have a favourite way to structure your libraries? Let me know in the comments! I have my code review on this later in the week, fingers crossed they like it! (Do developers ever get past the point where they want their code to be liked, I wonder?) Perhaps I should instead wish that at least I learn something from it.


Cheers,


Leah

Comments