Offline Review process for LabVIEW: Which tools and workflows do you use?

[mclordo]

Hello everyone,

I am currently faced with the task of implementing a Continuous Integration CI toolchain and the corresponding workflow for LabVIEW. A crucial component is the offline review process, which I want to include. So after reaching a certain point in development - such as after a feature merge, milestone, or a set number of commits - an offline review is triggered. The reviewer then examines the code changes at a time that suits them. There are several tools for text-based programming, like JetBrains Space, that efficiently support this review process. However, these tools are only partially suitable for VIs due to their binary format. I've explored various options and come across some interesting approaches, most of them focused on a peer review, but none of them seem to utilize a dedicated offline review tool for LabVIEW specifically:

https://forums.ni.com/t5/LabVIEW-Development-Best/Improving-Code-Quality-and-Performing-Code-Reviews 

https://forums.ni.com/t5/North-Oakland-County-LabVIEW/Code-Review-and-VI-Analyzer-5-6-20

https://forums.ni.com/t5/Random-Ramblings-on-LabVIEW/SSDC-Document-Deep-Dive-Code-Review-Checklist 

https://www.ni.com/en/shop/labview/doing-code-reviews.html

https://argentaconsult.com/_userfiles/pages/files/cla_2018_code_reviews.pdf

https://learn.ni.com/learning-paths/implementing-a-test-strategy-in-labview

Tom's LabVIEW Adventure - 4 - How to do Code Reviews 

https://stravaro.com/lvjournal/2012/08/labview-code-review-session-at-niweek 

I would be interested to know whether any of you use such tools in your workflow, perhaps with customizations, or whether you have developed your own solutions for the review process of LabVIEW code. What experiences have you had, and which approaches or tools have made the review process easier for you?

I look forward to your suggestions and ideas!

Best regards

[leahmedwards]

Interesting question! I'm used to doing offline reviews before a merge quite informally, just writing a note on the feature ticket that it had been done. I use the graphical TortoiseGit log in Windows Explorer to see what changes have been made, and look at each LabVIEW diff launched manually from TortoiseGit which I set up to diff with LabVIEW for .vi, .ctl etc. 

I do have some ideas though for building something more formal. Some parts are easier than others.

- Trigger = pushing a #review tag in git? You could assume you want to look at changes since the last review or since it last branched from main

- Other triggers might be more appropriate e.g. find some way of passing in a commit hash to compare against.

- You can write code to list the changed files only, between the two commits. I have done this before for 'compare to last commit'. 

- You could make it send out an email (to a specified reviewer e.g. in yaml file or some other method) listing the changed files.

- It would be nice if the email could have each file path as a hyperlink to open up the appropriate diff. The only way I can think of doing this in my toolchain is making a folder of .bat files which execute commands that call the diff from TortoiseGit ( https://tortoisegit.org/docs/tortoisegit/tgit-automation.html ). Not very neat. 

Just some ideas, keen to hear what other people think! 

[hunter_jki]

At JKI we made an internal review tool for VIs using GIT

1. You point to a local GIT checkout, and specify the branch name to compare to. It had to do some magic to get both copies of the code checked out in a way that won't break LabVIEW.
2. It would then do a binary diff to get the list of added/removed/changed VIs.

3. It then calls into LVDiff to display the UI diff for each VI as you click down the change list.


This tool was primarily developed for LabVIEW 2020, In LabVIEW 2024, there are some new diff features that should make this tool even more powerful, but I am just starting to switch some of my projects over.

The Diff tool is just an internal tool, but JKI offers a CI/CD suite including Static Analysis, Unit Testing, Automated Builds, and Security audit tools. I love that no one can commit a broken VI to our repo with our tools, so that code review is not the only tool you have to monitor code quality.

[mclordo]

---

@hunter_jki wrote:

At JKI we made an internal review tool for VIs using GIT

---

This internal tool is it to be compared with this toolkit: LabVIEW Code Comparison Tool for Git from GLA Summit 2024?

---

@hunter_jki wrote:

This tool was primarily developed for LabVIEW 2020, In LabVIEW 2024, there are some new diff features that should make this tool even more powerful, but I am just starting to switch some of my projects over.

Which new diff features in 2024 do you mean?

[mysticfree]

Is your tool available to the public?

Thanks,

Ron

[Taggart]

---

@mysticfree wrote:

Is your tool available to the public?

Thanks,

Ron

---

 I'm sure JKI's tool is nice and polished but if you want something less polished and free,

if you set up LVCompare using this: https://blog.sasworkshops.com/the-easiest-way-to-setup-lvcompare-and-lvmerge/

You can use the gitdifftool command and get basically the same thing for free. It's certainly not polished - its just a terminal interface, no fancy UI and you have to clone the repository -but it does the job. It works well for developers. For a manager who doesn't write LabVIEW code, probably not sufficient.

If you want a nicer polished experience, then throw Jim some money (assuming they are interested in selling it). I'm sure it's worth it.

[avogadro5]

We have a custom tool that hooks into our GitLab instance via its REST API:

1. Retrieve list of merge requests assigned to user running tool
2. On selection, clone each commit being compared and dependencies to independent temp folders
   1. Disk hierarchies for our code in git are preserved
   2. Links to symbolic paths (vi.lib etc) are independent of location on disk so these are preserved as well
   3. There are various ways to speed this up by not retrieving the whole git history every time
3. Display a UI showing each changed/added/deleted file
4. On selection, open file(s) in temp projects, one temp project for each side of the comparison
   • This step along with the independent folder structures allows both sides of the compare to compile (no broken arrow) because no files have to be renamed since they're in separate app instances
5. If comparison is a modified VI, use the "project\procmphier.llb\CMP Compare two VIs.vi" to open the LVCompare window
   • Note the 2 app ref inputs...

Comparing LVClass member VIs correctly requires this hassle since renaming anything breaks the class and all its VIs; you HAVE to use 2 app instances and you HAVE to have both versions of the class on disk in different folders.

We have a similar tool for merges (which requires 4 app instances) but LVMerge straight up sucks so it is barely useful.