How do you organize your projects?

[eaolson]

I'm always looking for better ways to organize my work and other tips that can make me more productive. So the other day I was wondering how people organize their different LabVIEW projects. I'm a lone developer, so my stuff is probably on the small scale side of things. Lately, every project I've been working on gets its own folder, everything is Subversion controlled, and I'm trying to standardize on how I organize the subfolders:

• the project root directory gets an overall .lvproj file and the top-level VI, along with any INI file that will be loaded
  
• subVIs - all subVIs under the top-level VI go here. If the number of files becomes large, it gets divided further by category.
  
• typedefs - for typedefs used by the subVIs
  
• controls - for custom GUI components
  
• docs - non-LabVIEW documentation for the VI
  
• HardwareDriver1, etc. - reusable components like hardware drivers are separate projects and are checked into their own directory using svn-externals
  
• build - (unversioned) EXE builds and installers get generated into this directory. For some reason, LabVIEW seems to want to build into the parent of the project by default, which seems confusing to me.
  

Components that I know are going to be used by other projects get handled similarly, but there's a "Hardware Driver Class" subfolder that holds the reusable part. That way I don't have to check out the .lvproj file and the test suite in projects that use the driver. (Note: I discovered too late that there's an annoying limitation to Subversion that you can't check out files into a directory that has a space in it.)

So I was wondering how everyone else handles project organization. I know Package Manager has recently undergone some updates that might handle some of this for me, but I haven't had a chance to look at it much and, frankly, I just don't need another tool.

[ASTDan]

Check out this website.

http://www.bloomy.com/lvstyle/loginform.ph...e/downloads.php

Peter Bloom of bloomy controls has a file template that is a very good starting point for project organization. I think he also talks about this in the LabVIEW style guide.

[Antoine Chalons]

QUOTE (ASTDan @ Sep 18 2008, 08:06 PM)

Check out this website.

http://www.bloomy.com/lvstyle/loginform.ph...e/downloads.php

Peter Bloom of bloomy controls has a file template that is a very good starting point for project organization. I think he also talks about this in the LabVIEW style guide.

That is a good starting point indeed !

We use a similar project template folder and I think this is also what NI recommends .

[jdunham]

QUOTE (eaolson @ Sep 18 2008, 11:03 AM)

• the project root directory gets an overall .lvproj file and the top-level VI, along with any INI file that will be loaded
  
• subVIs - all subVIs under the top-level VI go here. If the number of files becomes large, it gets divided further by category.
  
• typedefs - for typedefs used by the subVIs
  
• controls - for custom GUI components
  
• docs - non-LabVIEW documentation for the VI
  
• HardwareDriver1, etc. - reusable components like hardware drivers are separate projects and are checked into their own directory using svn-externals
  
• build - (unversioned) EXE builds and installers get generated into this directory. For some reason, LabVIEW seems to want to build into the parent of the project by default, which seems confusing to me.
  

I don't believe it's good to keep typedefs separately. Even if you are not using OOP, it's better to group your files by topic rather than file type. If you are doing a report, do you keep your Word files in a separate folder from your Excel files? Even if the typedefs are used across your code, they should be "owned" by some functional group. GUI controls are sort of the same. Some may be a "window" into one of your modules, and should be grouped with the rest of that module/group for maximum reusability.

The build folder should not be under your project. That way it is easy to check in all of your source code without having to ignore all the build output.

The other thing I do is under my project, I have a folder called "source" and all code, including the lvproj, is under that. So under my project, I typically have

• Source
  
• Config
  
• Data
  
• Doc-internal
  
• Doc-external
  
• Build
  

What's nice about this is that it's easy to check out different versions (Source, Source.version23, Source.latestrelease, source.trunk, etc.) of the source and run them against the same data and config files as needed.

The reason for two documentation folders is that I think it's useful to separate stuff generated internally (it's a lot like source code and should always be under revision control), from stuff you get from customers and vendors, which is very useful, but you didn't get paid to generate, and is not part of your intellectual property.

[eaolson]

QUOTE (ASTDan @ Sep 18 2008, 01:06 PM)

Peter Bloom of bloomy controls has a file template that is a very good starting point for project organization. I think he also talks about this in the LabVIEW style guide.

I read his Style Guide a while back, but forgot he mentioned this sort of thing. That's a very thorough file template. There's also a good Project Specification template at the same location.

[nhollenback]

I usually have several folders rather than just one. Devise a process (what ever it may be - www.thinkinging.com has good article) for tracking all VIs that may go into a reuse library. I also have a "Not Used" folder for prototypes and misc code that is no longer currently part of the project, but something that I don't want to toss.