Project Templates

Hey, I’m back. It’s been a while without posting, and now I’m bringing something that I’ve been researching in the past few weeks.

It’s been about project templates, more precisely, project structures.

What is known…

That was always my complaint about LabVIEW, I’ve never seen a similar a project structure, and it is easy to lose ourselves inside folders and more folders without finding what you want. Sometimes the Project File (.lvproj) is well organized, but it does not reflect the folder hierarchy.

I believe that this happens mainly due the nature of the LabVIEW origin, where it wasn’t, in the early days, a language for applying OOP techniques or even Software Engineering.

OOP has only recently gained preference among LV developers and software engineering methodologies are still growing inside the community. Considering the age of the language, these are kind of new concepts (I believe .lvproj too), therefore, I find it reasonable that we don’t have a concise opinion about it.

In that matter, I believe one day NI could embrace this idea, and encourage people to use a unified project structure. There are guidelines but I have not found a structure proposal.

• File and Project Organization in LabVIEW NXG
• Best Practices for Managing NI LabVIEW Applications Using the Project Explorer
• Prevent VI Cross-linking with the Enhanced LabVIEW Project

Until there (if “there” will ever happen) I researched some project structures across multiple languages, and I picked some ideas that I could reuse and implement also in LabVIEW.

Inspiration

After this research, I paid attention mainly to the use of those folders in these languages, i.e. .NET (C#) Ruby on Rails, Java, among others, and all of them have similar structure in general.

I really envy Rails Community, they enforce a project structure (See Scaffolding), or else, things won’t work very nice. That’s bad? Maybe, but if you look at the bright side, in every project in the community or company that you will work, or code that you review, you will find a similar structure and the code is expected to be in the same places. Isn’t that great?

If you agree or not, the consensus is always the same. In your company (organization), the folder structure must always be the same, at least there.

The Structure

Aside these points raised before, I also took in consideration the fact that we use Git Source Control. So, here it is the structure and the comments about every folder and file.

• build – This directory contains the build files. As they are build files, usually the content is ignored by the source code control;
• config – This directory contains configuration files such as XML’s, JSON’s, INI’s files that are needed within the project.
• docs – This directory contains all documentation related to the project, such as UML diagrams, use case stories and requirements.
• lib – This directory contains all libraries (dependencies) that are in some part reuse code. This folder will be used by my dependency manager as described in my previous post.
• src – This directory contains the source code related to the repository. Definitely the most important. Mandatory.
• test – This directory contains the test code. In sub-folders you will place different tests such as unit, mock, functional and among others. The important is to test.
• vendor – This directory contains all dependencies that I can’t have control of, that means, third party libraries. For this reason, this specific folder is not automatically ignored, in case you want to make sure the code is not lost.
• .gitignore – This file contains all the ignored files for the version control system, i.e. *.alias and *.lvlps.
• CHANGELOG.md – This file contains information about your code versions. Very straight about listing the addded features or removed/deprecated ones. Use this file. We don’t want to list commits logs in every repository to see what you’ve changed (future post on it).
• LICENSE – if applicable you may use in your open source project.
• Project.lvproj – This is the main project file where it holds the dependency and the main source code, named after the “Application Name”. It is used also for managing targets in real-time projects.
• README.md – This file contains precious information about your project/repository. Use it wisely to inform the visitors and reviewers about your code and its intent. Visit Make a Readme for more information.

If you want to have a look at finished structure. Here it is a link for a template project.

Starting the Project from Scratch

More important than having a defined structure, it is being able to deliver this easily to all developers, so they can start a project from scratch with a pre-defined structure.

For this issue I’ve found two possibilities (edit “three”):

LabVIEW Project Template Create Dialog

For this one, there is already some information in NI about creating these Custom Project Templates, but I found valuable information also in Elijah Kerry’s Blog, which clarified some points in a more customized approach.

In summary, if you want to customize your projects, you must follow these steps:

1. Create a LabVIEW Class and inherit from the MetaDataObj.lvclass in vi.lib.
2. Edit mainly three VIs:
   1. Override “Read Spec Page Path” – where you point your Spec Page VI.
   2. Create PostCopyScripting.vi – use this for your scripting;
   3. Create SpecPage.vi – use this for the user interaction. This VI will show in the Create Project Dialog.
3. Don’t try to do this from zero. Use the shipping examples, i.e. Actor Framework.
4. Create the Meta Data XML.
5. Put in the ProjectTemplate folder.

Git Project Template

The other option is, if you are a Gitlab Premium User (not a free user), you can choose one of your groups to serve as a template source. So when creating new repositories you may elect this template as origin of your project (exact replica).

Unfortunately I don’t have a premium subscription (yet) but that is a good alternative, because you may set other project properties reusable for all your repositories.

Scripting

Later I wrote about scripting with bash. Here is the link.

Use it

If you found it interesting and you want to use this structure, please use it. Below is the link for the “template repository” and the VIPM for installing this template in your LabVIEW Installation. If you want to modify it, that’s up to you, the source code is available.

Project Template Gitlab

VIP for LabVIEW

What about you? What project structure have you been using? Leave your comments below.

EDIT: later, planning a software I realized that I would need a folder for third party libraries that I don’t have control of it. Therefore, I am suggesting the vendor folder.