Hi Joe,
Thanks very much for the feedback. It definitely sounds your development team would not find the stylistic checks provided by the VI Analyzer to be useful based on your current way of doing things. However, the VI Analyzer can prove extremely useful as a debugging tool, and I'm guessing that your development team does have to debug VIs on occasion. 🙂
Here's a scenario...imagine a very simple VI that uses the Increment function to add 1 to the value of a control and then sends the result to an indicator. However, when you run the VI, the number does not increment. A quick check of the wires shows that you accidentally wired the input wire of the Increment directly under the Increment's output terminal and straight to the indicator, such that it *looks* like you're wiring from the output of the function. Now this scenario would be extremely easy to debug in this simple VI, but what if this wiring error was present somewhere within a very large application, and you had to spend hours debugging some incorrect behavior of your application only to discover this errant wire as the culprit? There are actually two tests in the VI Analyzer that can very quickly discover this error...the Unused Code test would flag the Increment function as being unused (since its output wasn't wired), and the Wires Under Objects test would flag the input wire as going under the output terminal of the function.
Here's another scenario...imagine another simple VI that takes an input array and multiplies it by some constant value to scale all the values in the array. However, when you look at the VI Properties of the VI, it takes up over 8 MB of disk space! The reason for this is that someone, at some point, accidentally chose the "Make Current Values Default" option on the VI, and there were a million values in the array output indicator when they did it. Again, an easy situation to solve when looking at this simple VI, but not so easy if this problem existed in a large application. And again, there are two VI Analyzer tests that would help you discover this error...the VI Size test (for obvious reasons), and the Array Default Values test (which will flag any array control/indicator that is wired to the connector pane and has a non-empty default value). This is actually a real-life example...one of my colleagues used the VI Analyzer as part of a code review for another group internal to NI and discovered this very problem in one of their VIs they were going to ship in a LabVIEW toolkit.
I could go on and on here, but the point is that the VI Analyzer is much more than a style-checking tool, although many customers and internal NI groups have found it very useful in this regard. I would say that for your average LabVIEW programmer, the debugging potential of the VI Analyzer is by far its most compelling feature.
As for your other question, you are correct that the VI Analyzer is an edit-time tool, and does not perform run-time analysis. I agree with you that a run-time analysis tool for LabVIEW would definitely be useful.
Finally, you asked if NI uses the VI Analyzer as a matter of policy. The answer is yes, we have several groups internal to NI that use the VI Analyzer. Some groups use it informally as an aid with code reviews, while other groups have completely adopted it into their development and build processes.
I really appreciate your feedback. Please let me know if you have any other questions or comments.
-D
