LabVIEW VI Analyzer Toolkit Overview

This article is part of a series on software engineering practices and tools for large application development in LabVIEW. Click here to view the list of other articles

Improve the quality and readability of graphical code developed in LabVIEW through the use of the VI Analyzer toolkit. Configure over 60 tests for automated code review and static code analysis of all VIs in an application.

Use the VI Analyzer as a debugging tool and to avoid overlooking improper coding techniques that could impact an application’s performance, functionality, or maintainability. Enforce good programming practices and coding styles within teams of developers in order to ensure the readability and functionality of code. Overall, use the VI Analyzer Toolkit regularly to develop high-quality, robust LabVIEW applications.

VI Analyzer Description

Use the LabVIEW VI Analyzer Toolkit to improve code quality and catch potential problems earlier during development. The VI Analyzer automates code reviews and enables more exhaustive code analysis. Run the toolkit interactively from within the development environment or programmatically using the LabVIEW API. Test parameters can be customized through a configuration dialog and preferences can be saved for later use. Once you make your selection, the VI Analyzer Toolkit loads each test into memory and then runs the tests on each of your selected VIs and generates a report listing all the possible improvements or potential problems that the tests identified. 

The VI Analyzer provides the following for each individual recommendation: 

• Information about what the tests observed 
• A list of what the tests discovered about the VI 
• A link to the VI section tested so you can easily identify the VI area that may need improvements

You can choose the improvements you want to make and then rerun the tests. You also can save your test configuration to run the same tests later. Additionally, you can save the report as either a text file or as an HTML document, so you can reopen it at any time and share it with other developers or store it along with the VIs in a source code control utility. 

• Visit the online store to see pricing information and purchase this toolkit. 
• Evaluate the LabVIEW VI Analyzer Toolkit online
• Introduction to the LabVIEW VI Analyzer Toolkit Tutorial

Test Overviews

The following section describes the details of each test that is included with the VI Analyzer.

Block Diagram Test Details

Tests in the Block Diagram category of VI Analyzer tests analyze VI performance and style related to the block diagram. The VI Analyzer groups the Block Diagram tests into three subcategories: Performance, Style, and Warnings.

Performance

The tests in the following list analyze coding conventions that affect VI performance.

• Arrays and Strings in Loops—Checks loops to see if they contain Build Array or Concatenate Strings functions. Avoid using these functions in loops because each call to them requires a dynamic resizing of the array or string, which can affect memory and processor time. This test does not check timed loops.
• Coercion Dots—Checks the total number of coercion dots on the block diagram and the number of coercion dots on individual wires and compares them to user-specified limits.
• Enabled Debugging—Checks whether debugging is enabled or disabled. Disabling debugging improves VI performance.
• Wait in While Loop—Checks While Loops with front panel control terminals for structures or functions other than I/O functions that regulate the speed of the While Loop.
• Wired Terminals in Subdiagrams—Checks to see if any control or indicator that is wired on the connector pane does not reside within the top-level diagram. In order to avoid unnecessary memory copies, place control and indicator terminals that are wired on the connector pane should be placed on the top-level diagram.

Style

The tests in the following list analyze block diagrams for issues related to LabVIEW style. Refer to the LabVIEW Style Checklist for information about LabVIEW style.

• Backwards Wires—Checks whether wires flow from left to right.
• Control Terminal Label Visible—Checks if labels of block diagram control terminals are visible. To easily identify control terminals on the block diagram, always make labels visible.
• Control Terminal Wiring—Checks whether wires exit control terminals from the right side and enter indicator terminals on the left side.
• Sequence Structure Usage—Checks whether the block diagram includes Stacked Sequence structures that contain more than the user-specified maximum number of frames. The test does not check Flat Sequence structures.
• String Constant Style—Checks the style of string constants on the block diagram. String constants containing no characters fail the test. Replace them with an empty string constant. String constants set to Normal Display that contain only white space—such as spaces, tabs, or line feeds—fail the test. Set the constants to '\' Codes Display to improve block diagram readability.
• Unused Code—Checks for unnecessary code on the block diagram.
• Wire Bends—Compares the total number of bends on a wire to a user-specified maximum and compares the length of each wire segment to a user-specified minimum.
• Wires Under Objects—Checks for wires that run under objects or other wires.

Warnings

The tests in the following list analyze block diagrams for potential design problems.

• Adding Array Size Elements—Checks whether the Add Array Elements function connects to the output of the Array Size function to determine the size of a multidimensional array. Wire the Multiply Array Elements function to the size(s) output of the Array Size function to determine whether a multidimensional array is empty.
• Breakpoint Detection—Checks for breakpoints on the block diagram, including breakpoints on wires, nodes, and subdiagrams.
• Bundling Duplicate Names—Checks element names in the Bundle By Name and Unbundle By Name functions for duplicates. Duplicate elements can cause confusing and sometimes incorrect block diagram behavior.
• Error Cluster Wired—Checks that the error output on a block diagram node is wired. You can set the test to ignore VIs with automatic error handling disabled. You also can ignore nodes that usually have unwired error outputs.
• For Loop Iteration Count—Checks For Loops to ensure that the VI does not use both auto-indexing arrays and the N terminal to govern the number of iterations the For Loop runs. You also can check for multiple auto-indexing arrays governing the iteration count.
• Globals and Locals—Checks whether a block diagram contains global and local variables.
• Hidden Objects in Structures—Checks whether any objects in structures are hidden outside the visible bounds of the structure.
• Hidden Tunnels—Checks tunnels, shift registers, and other structure border elements to see if they overlap each other. Overlapping tunnels can make your block diagram difficult to read. The test currently does not check dynamic event tunnels, tunnels on Timed Loops with frames, or tunnels on Timed Sequence Structures.
• Indexer Datatype—Checks functions that index array elements and string characters to ensure that signed or unsigned 8-bit or 16-bit integer data types do not index string or array elements. The test ignores functions that use constants for indexing.
• Pattern Label—Checks whether a file dialog box that uses file patterns specifies a pattern label. The items you can check are the File Dialog Express VI and the browse options on a path control.
• Reentrant VI Issues—Checks for uninitialized shift registers and non-reentrant subVIs in a reentrant VI. Because reentrant VIs maintain multiple data spaces, unexpected results can occur when using uninitialized shift registers. Additionally, parallelism could be inhibited if the reentrant VI calls non-reentrant subVIs.
• Typedef Cluster Constants—Checks cluster constants on the block diagram that are linked to type definition controls to determine whether their values match the default value of the type definition control. If a constant has a non-default value and the structure of the type definition changes, the value of the constant might reset. Use the Bundle By Name function to change the value of any elements inside a cluster constant linked to a type definition control.

Documentation Test Details

Tests in the Documentation category of VI Analyzer tests check for documentation issues within VIs. The VI Analyzer groups the Documentation tests into the Developer and User subcategories.

Developer

The tests in the following list ensure that VIs contain documentation that benefits other developers.

• Comment Usage—Checks whether the block diagram contains a minimum user-specified number of comments. The test also can check whether all subdiagrams of multiframe structures, such as Case, Event, and sequence structures, contain at least one comment.
• Label Call Library Nodes—Checks Call Library Function Nodes on the block diagram for labels. You can improve the readability of a VI by using the label of a Call Library Function Node to describe the function you are calling in a shared library. The test fails if a Call Library Function Node has no label or the default label.
• Revision History—Checks for revision history comments. Clear the revision history when you complete a VI so users cannot see developer comments.

User

The tests in the following list ensure that VIs contain documentation that benefits users.

• Spell Check—Spell checks VIs, front panels, and block diagrams.
• VI Documentation—Checks for text in the VI description, control description, and/or tip strip fields on all controls.

Front Panel Tests

Tests in the Front Panel category of VI Analyzer tests analyze front panel design and style. The VI Analyzer groups the Front Panel tests into the SubVI and User Interface subcategories.

SubVI

The tests in the following list check the appearance and arrangement of front panel controls on VIs used as subVIs.

• Array Default Values—Checks charts, graphs, and arrays on a front panel for empty default values. Saving non-empty default values inside charts, graphs, or arrays uses memory unnecessarily. When the VI runs, it overwrites values wired to indicators on the block diagram. If a subVI is using the VI, the VI overwrites values wired to controls connected to the connector pane.
• Cluster Sized to Fit—Checks that front panel clusters are set to Size to Fit, Arrange Horizontally, or Arrange Vertically. If you do not select one of these autosizing options, cluster objects might not be visible to the user.
• Control Alignment—Checks that the alignment of controls on the front panel roughly matches the alignment of controls on the connector pane.

User Interface

The tests in the following list analyze user interface design.

• Clipped Text—Checks that any visible text on the front panel is not cut off. This includes text in control labels, control captions, free labels, and text controls such as strings and paths. The test cannot check the text inside listboxes, tables, tree controls, and tab controls.
• Dialog Controls—Checks that front panel controls are from the System palette. The test ignores controls that do not have a dialog counterpart.
• Duplicate Control Labels—Checks that controls on the front panel do not share the same label.
• Empty List Items—Checks listbox, multicolumn listbox, table, and tree controls to ensure that they are empty. The VI populates the contents of these controls when it runs, so saving a VI with contents in these controls uses memory unnecessarily.
• Font Usage—Checks that front panel controls, indicators, and free labels use user-specified symbolic fonts, such as application, system, or dialog fonts.
• Overlapping Controls—Checks that front panel controls do not overlap. The test does not analyze front panel decorations.
• Panel Size and Position—Checks that a front panel completely resides within the bounds of the screen. The test also checks whether the front panel is larger than the maximum specified width and height. If you are using a multi-monitor system, the test fails if the panel does not reside entirely within the bounds of the primary monitor. This test works only on standard, control, and global VIs.
• Transparent Labels—Checks that free labels, control labels, and control captions all have transparent backgrounds.

General Tests

Tests in the General category of VI Analyzer tests analyze aspects of VIs not covered in the Block Diagram, Documentation, or Front Panel categories. The VI Analyzer groups the General tests into three subcategories: File Properties, Icon and Connector Pane, and VI Properties.

File Properties

The tests in the following list analyze properties of the VI as a file, such as filename and size.

• SubVI and TypeDef Locations—Checks that subVIs and type definitions reside in one of an arbitrary number of user-specified locations (paths and LLBs). If you do not specify a location, the test passes. The test does not check Express VIs on a block diagram.
• VI Extension—Checks the filename extension. The test fails for any VI that does not have a .vi or .vit extension, or for any custom control that does not have a .ctl or .ctt extension. The test is case insensitive.
• VI Name—Checks the name of a VI for potentially invalid characters.
• VI Saved Version—Checks that the VI is saved in the most current version of LabVIEW.
• VI Size—Compares the file size of a VI to the maximum allowable size you specify.

Icon and Connector Pane

The tests in the following list analyze VI icon and connector pane style issues.

• Connected Pane Terminals—Checks that control and indicator terminals on the connector pane are wired on the block diagram.
• Connector Pane Alignment—Checks that inputs wire to connector pane terminals on the left side and that outputs wire to connector pane terminals on the right side.
• Connector Pane Pattern—Checks that the connector pane pattern, regardless of rotation, matches one of the user-specified connector pane patterns.
• Default Icon—Checks that VI icons of standard and polymorphic VIs are neither default nor empty.
• Error Style—Checks that error connections appear in the lower-left and lower-right corners of the connector pane. This part of the test runs only if the connector pane wires a single error in and a single error out terminal. The test also checks whether an error case appears around the contents of the block diagram.
• Icon Size and Border—Checks that the icon image is 32 × 32 pixels in size and has a solid border. The test does not check the icons of control or global VIs.
• Polymorphic Terminals—Checks that terminals on all instances of a polymorphic VI appear in the same position on the connector pane of the instance VI. The test does not analyze broken polymorphic VIs.
• Terminal Connection Type—Checks that controls and indicators on the connector pane that match user-specified names or patterns include the user-specified terminal connection type, such as required, recommended, or optional.
• Terminal Positions—Checks that controls and indicators connected to a connector pane that match user-specified names or patterns are located in certain positions.

VI Properties

The tests in the following list analyze the overall setup of a VI.

• Broken VI—Checks for broken VIs.
• Built Application Compatibility—Checks for properties or methods that are not supported in built applications. Run this test on any VIs you want to build into an application to ensure they will function properly.
• Driver Usage—Checks for subVIs, functions, or property nodes that are part of National Instruments driver software packages. This test does not check for Express VIs that are part of the driver software packages.
• Platform Portability—Checks for potential problems that might occur when you attempt to port a VI from one operating system to another.
• Removed Diagram—Checks whether the block diagram is present. Do not remove a block diagram from a VI because you cannot recover it. You can password protect a VI if you do not want users to view the block diagram.
• Toolkit Usage—Checks whether subVIs are National Instrument toolkit VIs. When you distribute a VI that includes toolkit VIs as subVIs, each computer that runs the VI must have the toolkit VIs installed or the VI does not run correctly.
• VI Lock State—Checks the lock state of a VI against the user-specified lock state(s).

 

 

Reader Comments | Submit a comment »