Directory Organization in a large application

[JDave]

I am starting on a large project and I don't want to end up with one folder containing 500 VIs. I wanted to ask what people have done (that they have liked or disliked) for organizing such a project. Do you just place larger tools in their own folders and then have some misc. folders for random or common VIs?

I am not going to use GOOP, for various reasons, if this affects your responses.

Thanks,

David

[Chris Davis]

I am starting on a large project and I don't want to end up with one folder containing 500 VIs. I wanted to ask what people have done (that they have liked or disliked) for organizing such a project. Do you just place larger tools in their own folders and then have some misc. folders for random or common VIs?

I am not going to use GOOP, for various reasons, if this affects your responses.

Thanks,

David

I use a simple directory structure that has served me well, but I don't have any projects that are 500 vis big. My biggest is ~200.

For a project called MyProject I will have

MyProject GUI

Holds all VIs that will appear to the user.

MyProject Subroutines

Self explanitory...

MyProject Controls

Self explanitory

exe build

Holds the EXE and any other associated pieces that are needed to build the install package / EXE. Since I typically use the NSIS installer instead of the NI MSI builder I have a build script here too. Consequently since I started using OpenG Builder I also have the OpenG Builder script and a Pre and Post build subroutine here.

I know this is a rather simplistic subdirectory setup, but it works for me.

[crelf]

Designing a folder structre can be a little odd due since you often can't really replicate the depth of you code That said, my folders are usually structured with modules in mind - irrespective whether you use GOOP or not, there's plenty of good reasons to keep modules separated in their own space - reuse for one: it's much easier to copy reuasble components across to new projects. I usually start with a template (not a vit, but a whole project architecture) that I've honed over the years, and there's a folder for common components (that the other components share) as well as folders for documentation (I use the VI Engineering documentation tool for that). I'm not a fan of keeping all my UI VIs in one folder - I don't really see the reason for it - I'd rather keep VIs that share more than a show front panel attribute together. I also only have my splash screen launcher, top level VI, their associated ini files and the project file in the top level folder - I have a separate folder, parallel to the top level code folder, that has all the appplication and installer builds in it.

[didierj]

Usually a project folder is divided first into

- Documents: as it says, descriptions of the code

- Work: The place where I put the vi's

- Build: The place where the app builder puts the exe and installer

- Archive: list of zip-archives containing "Work" for the different revisions

In the project folder itself is also

- bld-file

- app-icon

- revision-history (usually a simple text file).

the "Work" directory is the further divided into module-folders as crelf described (since I use openGoop the subdivision is done automaticly).

In "Work" is also

- top-vi

- vi-list vi (containing top-vi and all dynamically called vi's)

- ini-file

- maybe a few more vi's that I can't assign to a specific module

- dll's.

Didier

[JDave]

Thanks for the responses thus far. On my last project (~60 of my own VIs plus some OpenG and driver VIs) I used different folders for GUI VIs, subVIs, drivers, and then a folder for subVIs that had a direct reuse capability (mostly because I was building cool things as I was going and I wanted to get at them easier in the future). Since this project is looking more weighty, I appreciate some other ideas.

Organizing the code is always interesting. Though when I was coding in C++ a lot of the smaller functions were just contained inside of the larger files. One thing I have really liked about LabVIEW is that each time I solve a problem (however small) I have a highly reusable block to drop onto other programs. That is wonderful. But it does make for a few more files...

Thanks again,

David

[lavezza]

My suggestion is to really think about how you want the code orgainized before the project gets too big to change it. I think this is one area where programmers don't spend enough time coming up with a good solution.

Our program isn't organized very well and it is a real pain. We basically have a common app framework with specific code developed for each project. Until recently, project code and common code were mixed together. It was a real nightmare to split them apart.

We now have a common hierarchy of 356 nested folders containing 6913 files (VI's and perl scripts). The project I'm working on has a project hierarchy of 198 nested folders with 2063 files. As you can imagine, this would be hard to digest even if the orgainization was perfect.

So, as your project gets bigger, if you realize your file structure isn't scaling well, fix it right away.

Pat