VI Analyzer and Git

For a while we’ve been trying to adopt good software engineering practices with LabVIEW.

We’ve been aware of the VI Analyzer and the benefits of including the static code analysis in the workflow.

For those who not know, the VI Analyzer Toolkit provides tests to your code that helps validate some style and practices and, in a way it helps standardize the code among the developers in your team.

The good thing about VI Analyzer is that it uses VI Scripting for doing those tests and therefore tests can be customizable or even created.

There is a group in NI Forums for those interested in downloading custom tests, or guides for creating your own.

VI Analyzer Enthusiasts Group

Running Tests – Traditional Approach

So, running tests with VI Analyzer is a good thing, right?

Yes, but nobody disagrees that it is as tedious task.

Selecting the tests, selecting VIs, running tests, waiting for results. Oh my, minutes have gone by already.

So I have a better decision, quit using. Wait, not a wise choice!

Running Tests – Custom Approach

I’ve just said it was a good thing to run VI Analyzer. It helps you keep your style, point some code optimizations, enforce minimum code documentation, and many other things.

Why give up?

So, I went for a research, looking for some alternatives to make my life easier in my workflow, and found this post from J. McNally, pointing a solution for two main problems:

• Amount of files tested every time;
• Therefore, amount of time spent;

The solution: run test only on changed files in SCC. There are many approachs, one leaves all this job to the CI Server, other you run in your machine before pushing to server. I like the idea of running tests before, instead of keeping failing in the server, where it should only make sure you didn’t mess up, so I chose them both.

Quick Drop Plugin

Unfortunately, I couldn’t follow the wire in James post, he did not post anything else related to this issue (I mean code), so I decided to invest in our own solution.

My main objective was to do a tool related to the Project Provider Framework (PPF), and having something to what I saw in the presentation of Chris Roebuck. But PPF is still some unknown waters for me, as it isn’t encouraged by NI either. This quest will stay for a future a post.

In this presentation he also showed an inclusion of the Analyzer in Git Hook Commits, which is good idea, but I found QD Plugins would be a nicer way to distribute to my team. In the end, it will always depend on your workflow, what and where is better for your team.

So, I developed in Quick Drop Plugin with the following sequence:

• Check for the working project of the current VI.
• Use its folder as base path (important to keep your .lvproj in the root).
• Check for modified (unstaged) files in Git (the command works, although I thinks it still needs little tweaks)
• Run VI analyzer in these VIs – two configuration files available (pressed shift alternate between these files);
• If the VI has no failed tests then stage it (git add) in the repository. It works but it has some weird behavior sometimes (still studying it and I’ll keep updating the source code).

I found this approach quite interesting, because:

• It saves me time;
• I can run tests really fast only on changed files from QD Plugin;
• I can alternate between two configuration files (i.e. fast or complete tests).
• An in the end as a plus, it ends up adding my file for a commit.

Download

Below is the link for downloading the package or the source code (just drop in the Quick Drop Plugin Folder).

Further information in QD Enthusiasts Group, as information on how to customize your trigger key. In this case I used [Ctrl + V], but you can change it to suit your needs.

Gitlab Project – VIPM Package

NI Forums – Discussion

How do you use VI Analyzer? Let me know leaving your comments below.