Test - Subdiagram Labels

[joerg.hampel]

This test fails if subdiagram labels in Case Structures, Event Structures, Disable Structures or for and while loops are not visible. It optionally fails also if subdiagram labels are visible but empty.

 

This test is saved in LabVIEW 2013. Follow the instructions here to install and use this test.

Revision History:

2018-01-12: Addressed Darren's suggestions.

[Darren]

Thanks for posting this test, I think it will be useful for developers trying to enforce coding standards involving subdiagram labels. I have some suggestions on ways to improve the test:

1. Show the Boolean Text of the checkboxes in the config VI instead of their labels/captions, because Boolean Text on checkboxes can be clicked to toggle the value, while labels/captions cannot.
2. Fix the misspelling of the label of "ixclude-error-structs" in the Config VI.
3. In the test VI, you have 'Traverse Generated Code' set to TRUE. You almost always want this option set to FALSE. You only need to set it to TRUE if you want to dig into code generated by XNodes and other code-generating nodes, which you almost never want to do in a VI Analyzer test.
4. Use the following hidden gem instead of reading the 'VI Type' property: vi.lib\addons\analyzer\_analyzerutils.llb\VIAnUtil Has Diagram.vi
5. You never need to close GObject references, so you can remove the Close Reference functions in your code. See Brainless LabVIEW for more info on which references you need to close vs. which ones LabVIEW will close for you.
6. Another Brainless LabVIEW suggestion...use conditional and concatenating tunnels to make heavily nested code (typical in scripting VIs like VI Analyzer tests) much simpler:
   
7. It looks like the test returns an identical failure for every frame of a structure that has an empty subdiagram label. I'd rather it return either (1) a single failure for the whole structure, or (2) a failure for every frame, but with the name of the frame to more easily identify it when browsing the failure results.

[joerg.hampel]

Brilliant, Darren, thank you very much for your suggestions! I actually had to smile when I saw how much room for improvement there can be in such a little piece of code 🙂

This reminds me of the LabVIEW Field Journal's Humility and Better Programming series: In an anecdote taken from a Weinberg book on "egoless programming", this guy Bill writes 13 lines of machine code, and when he's happy with it and shows it to his colleague Marilyn, she manages to find 20 errors. But instead of being defensive, he became amused. 

[Taggart]

I wouldn't call those errors. Just improvements.