Recently I was working in a Python project where I had the opportunity to use the pre-commit framework.
Setting up your CI pipeline for example, or creating a makefile in python projects is not a big thing to maintain code quality and standards in your project.. There are plenty of examples around. You can, for example, create a makefile to run all your tests locally, linters, formatters, but you always need to remember to do it.
That’s why there are git hooks, but git hooks are a bit cumbersome to set, specially if you have multiple things to run. That’s why the pre-commit framework came into play. Configurable and organized way to do it, specifying your hooks type. Although the name, it supports other git hooks.
Formatting and Code Analysis with LabVIEW
There are two reasons for the project I started here. First ,there is no “free” static code analysis in LabVIEW. You can get LabVIEW Community Edition and you can’t get VI Analyzer. This means code quality will stay behind in LV projects.
The second one is the formatting. Every time you need to save, before that you execute some muscle memory functions, like Arranging VI Windows, aligning things in the block diagram and so on.
I believe one of the best way is to do it before committing, and that’s why pre-commit becomes handy.
But wait, is there a LabVIEW (G) hook for pre-commit?
Unfortunately there wasn’t, not that I’ve found. Pre-commit itself does not support G Code, so I was expecting that it would not have that easy.
What I did was to create a Python Project as wrapper supported by pre-commit and from there call g-cli and each of the hooks.
Not without its challenges I made it and right now is published in my gitlab repository:
https://gitlab.com/felipe_public/pre-commit-hooks-g/
Using it
Setting pre-commit is straight forward, you can check it at their website pre-commit.com, as also the recommendations.
Right now, there are 3 hooks available for LabVIEW, but the idea is to expand this hooks over time, as new ideas and changes are integrated. I also made sure all those hooks are with a good level of tests, including different types of VIs.
- VI broke – checks if you are committing a broken VI (state bad).
- VI description – checks if the VI you are commiting has VI description.
- Yellow – a code formatter that can arrange VI Windows, set compiled code as source only, etc…
One of the interesting things about the pre-commit is if the code is formatted for example, the commit will fail, forcing you to stage the file again.
Example of pre-commit in action:
As you can see I got some failing code. Some of them have were failing. One was broken, and other one didn’t have the code style in shape. So, the code formatter help with the second, about the first one I needed to deal with.
After fixing and trying to commit again:
And done, everything all right.
Hopefully, this should help anyone in the pursue of the better code quality and better code standardization.
Felipe's Thoughts 