|
Use a type definition when you use the same unique control in more than one location or
when your project includes a large data structure that passes
between several subVIs.
|
Required
|
A type definition automatically propagates changes to the control or data structure
throughout all relevant VIs and subVIs.
|
N/A
|
|
Select
Autosize list view in the
Item tab for any properties nodes, such as Cluster Properties or Waveform Properties.
|
Required
|
The
Autosize list view option ensures that all element names are fully visible.
|
N/A
|
|
Make sure that data flows from left to right and that wires enter the diagram from the left and exit to the right.
|
Recommended
|
Although the positions of program elements do not determine execution order, avoiding right-to-left wiring helps users read
and comprehend the diagram.
Note
Only wires and structures determine execution order.
|
N/A
|
|
Avoid creating any backwards wires unless those wires connect to feedback nodes.
|
Recommended
|
Wires that cause data to flow from right to left contradict style best practices.
|
N/A
|
|
For subVIs and top-level VIs that do not contain loops, place controls on the far left and indicators on the far right.
|
Recommended
|
Placing controls and indicators in these positions increases readability and usability by giving users a familiar and expected
location to look for the controls and indicators.
|
N/A
|
|
For non-user interface subVIs, make sure all controls and indicators that are on the connector pane also reside on the top-level
diagram.
|
Recommended
|
N/A
|
N/A
|
|
Use a docked constant if the only purpose of the constant is to define a data type and the value is unimportant.
|
Recommended
|
Docked constants that contain meaningful values can inhibit the readability of the diagram.
If a docked constant is set to the default value, it will appear
hollow. If any other value is used, it will be a solid color.
|
N/A
|
|
If you display the list view of a node, make sure the entire name of the longest item in the node is visible.
|
Recommended
|
Also, resize the node for shorter names to reduce any extra space.
|
N/A
|
|
Use list view for all nodes imported with the Shared Library Interface (SLI) document type, and show the node label.
|
Recommended
|
List view helps users distinguish between SLI nodes and subVI nodes and also improves readability.
|
N/A
|
|
If you wire an enum to a Case Structure, make sure none of the cases are marked as the default case.
|
Recommended
|
One exception to this guideline is if the Case Structure only operates on one or a small number of the overall number of items in the enum.
|
N/A
|
|
If you wire a ring, string, or numeric to a Case Structure, remove any additional values from the string in the Case Selector Label.
|
Recommended
|
Removing additional values increases clarity.
|
See the
Case Values of a Case Structure section following this table for a visual example.
|
|
If possible, avoid using ellipsis notation for enum values.
|
Recommended
|
Enumerate all the values so that if you add a new value later, the diagram breaks and you can consciously handle the new enum
value. Use range notation sparingly.
|
N/A
|
|
If your VI includes its own clusters or enums on the diagram, define them with type
definitions.
|
Recommended
|
Type definitions allow you to manage these data types in one place and ensure that any
changes you make to a data type propagate across all relevant
VIs and subVIs.
|
N/A
|
|
Use comments to document the functionality of your code.
|
Recommended
|
N/A
|
N/A
|
|
Reference applicable VIs in comments instead of showing the labels on all subVIs in a diagram.
|
Recommended
|
When you display object labels, you cannot reposition them, so your diagram width must increase unnecessarily.
|
N/A
|
|
Consider whether or not your VI needs an error Case Structure surrounding its contents.
|
Recommended
|
If the error Case Structure is not handling critical running code, consider simply passing the error wire through all diagram nodes without creating
a case around the whole diagram.
You may want to use an error case if your VI is manipulating the error cluster at all. Using an error case allows you to case
out the relevant diagram so that your error manipulation code does not modify any error entering the VI.
|
High iteration loops and modal dialogs are examples of critical running code.
|
|
Arrange diagrams so that the primary wire travels in a straight line between nodes.
|
Recommended
|
The primary wire is typically a reference or error wire.
|
N/A
|
|
Keep approximately 20 pixels of white space between objects.
|
Recommended
|
An overcrowded diagram without adequate white space is difficult to read.
|
N/A
|
|
Expand array constants to display all array elements, plus one empty element at the end.
|
Recommended
|
Displaying all array elements with an empty space at the end helps users see the entirety of the array. If you do not have
enough space for a large array constant, display the scrollbar.
|
N/A
|
|
Use a comment to label long wires and identify their use.
|
Recommended
|
Wire comments are useful for identifying and describing wires that come from shift registers and long wires that span the
entire diagram.
|
N/A
|
|
Avoid bending wires when possible, and keep wires short.
|
Recommended
|
Wires with long, complicated paths are difficult to follow.
Note
Avoid replacing long wires with local or global variables.
|
N/A
|
|
Align and distribute nodes, terminals, and constants.
|
Recommended
|
When you align and distribute objects evenly, you can use straight wires to connect objects and create readable diagrams.
|
N/A
|
|
Avoid placing diagram objects, such as subVIs or structures, on top of wires, and avoid placing any wires under diagram objects
because the software can hide certain segments of the resulting wire.
|
Recommended
|
Draw wires so that you can clearly see if a wire connects to a terminal. Avoid wiring through structures if the structure
does not use the data in a wire.
|
N/A
|
|
Make sure control and indicator terminals on the connector pane do not reside inside structures on the diagram.
|
Recommended
|
The development environment can optimize subVI execution time when all controls and indicators on the connector pane reside
on the top-level diagram of the VI.
|
N/A
|
|
Save the VI with the most important frame of multi-framed structures, such as a Case Structure, displayed.
|
Recommended
|
Saving the VI with the most important case displayed increases readability because the user does not have to switch cases
immediately.
|
If you open a diagram and the error case that wraps the entire diagram is displayed first, you must switch to the no error
case to see the actual diagram code.
|
|
Maximize the performance of code on the diagram.
|
Recommended
|
When a program has large arrays or critical timing problems, you can use the following guidelines to maximize the performance
of the VI:
-
If possible, avoid building arrays using Build Array within a loop because the node makes repetitive calls to the memory manager. Instead, use auto-indexing or pre-size the array
and use Replace Array Subset to place values in the array. Also avoid using Concatenate Strings with strings because, in memory, the software handles strings as arrays of characters.
-
Choose the proper array data type to control the memory usage of the application.
-
Display only necessary information on the panel. Send data to indicators only if the data is different from what the indicator
already displays. Frequently updating panel indicators with new data can affect the performance of the VI, especially if you
display large amounts of data in graphs or charts.
|
Array data types can affect the memory usage of an application. For example, if your double-precision, floating-point array
of 100,000 values is actually storing single-precision, floating-point values, you are using memory inefficiently. In this
case, use an array of single-precision, floating-point values to match the data type stored in the array and reduce the memory
usage.
|
|
If your VI includes several I/O name controls, such as Waveform and Digital Waveform, that are stacked vertically, configure them to not show type.
|
Recommended
|
If you set I/O name controls to not show their type, you can maximize information density and avoid overlapping the controls.
|
N/A
|
