This is probably the most controversial of these recommendations. Some people would vehemently disagree with me about putting build files in SCC. I’m ok with that. I have my reasons and I do set some limitations to this practice. First, I do this so that a developer (me included) can set up the project on another computer and be able to execute it without having to compile again.
Secondly, I do have my limits. I don’t put large installers or executables that are hundreds of MB in SCC. That situation does not happen very often though.
Test is for code that you create for a project, but is not part of the build source. Any test VIs should go in test. For smaller projects, I usually throw out my file-naming scheme for this folder. That is part laziness, because it’s non-production code, and partly so it will be obvious to anyone looking at this folder that it is not production code and should not be considered part of the project source.
On larger projects where I write a lot of tests, I use more organization.
Only docs that you are creating for the project should go here. Reference materials should go in “Resource.”
All your VIPM packages, instrument driver installers, etc. should go in this folder. Any packages that the source code depends on to execute, that are not part of the source code itself, go here.
Any built libraries or assemblies from LabVIEW or any other language that the application calls can go here. Typically, you would never modify files in this folder. They contain purely compiled code.
This contains any reference materials (datasheets, manuals, etc.) that I need for a project. I also use this for non-code files that the project uses, such as images, icons, videos, and default configuration files. If you have some unique needs, like controlling the configuration files of several deployed devices, this would be a good place for that.
These are utilities, created in LabVIEW or not, that aid in development or configuration of the development environment for a user. Some examples:
- VIs that create simulation data
- Build scripts
- Installers for tools that are critical for development, like an SQLite database viewer installer
I use this folder when I need to do an intermediate export of source code to alter it in some way before building. You usually only need this when building more complex VI packages.
In summary, everything a developer needs to set up their environment should exist within SCC somewhere in this layout. There’s a place for everything, and everything in its place.
Now that you have your repository layout and project folder structure ready to go, keep an eye out for future blog posts around how you can improve the organization and naming of your projects.