LabVIEW Style Checklist

Run the VI to verify that controls and indicators with default values do not cause the VI to fail.

Note��Avoid setting default values for indicators such as graphs, arrays, and strings. Setting default values for these indicators can use unnecessary disk space.

If you set default values, you enable a function or VI to handle more options internally without requiring as much user interaction. For example, if you set a default value of 0 for the Write Delimited Spreadsheet VI, LabVIEW uses that default value to automatically present an empty file dialog and prompt for an input.

The three standard fonts, application, system, and dialog, vary depending on the platform you use. For example, preferences and video driver settings in Windows affect the size of the fonts. Text may appear larger or smaller on different systems. To compensate for font variations, allow extra space for larger fonts and enable the Size to Text option on the shortcut menu.

The Abort Execution button stops the VI immediately and prevents the VI from finishing the current iteration. If you abort a VI that uses external resources, such as external hardware, resources may remain in an unknown state because they were not reset or released properly.

Use the standard font unless you have a specific reason to use a different font. For example, you can use monospace fonts because they are proportionally spaced for string controls and indicators that constrict character use.

Place controls in the order of typical use. For top-level VIs visible to users, place the most important controls in the most prominent positions. For subVI front panels, place the controls and indicators of the subVI so that they correspond to the connector pane pattern.

For example, remove the index control and add a scrollbar to make an array style consistent with listbox style.

The following table lists the situations to use captions and labels and the corresponding examples.

Situation	Example
If the control is visible to the user, use captions to display a long description and add a short label to prevent using valuable space on the block diagram.	When you label a ring or slide control with options for volts, ohms, or amperes, selecting a caption such as "select units for display" is more usable than the label V/O/A. Use Property Nodes to change captions programmatically.
If the default value or unit is unusual, include default values and unit information in label names.	Include the default value of no error in parentheses for the error in parameter.
If you use the VI with the control on multiple platforms, avoid using special characters in control names.	Use degF instead of �F because the � symbol might not display correctly on all platforms.
If you use Boolean controls, use a name to give an indication of which state, TRUE or FALSE, corresponds to the function, such as "ON." Indicate the default state in parenthesis. For checkboxes and radio buttons, the user can click the Boolean text of the control, and the value of the Boolean control changes. Free labels next to a Boolean control can help clarify the meaning of each position on a switch.	Use free labels such as Cancel, Reset, and Initialize that describe the user action.

Default menus provide more options than are necessary and make sense for the particular application. Customize the menu options for an application to enhance its professional appearance.

Use the system controls in dialog boxes to prompt and gather settings and configuration information from the user. You also can use tab controls to group front panel controls and indicators in a smaller area and reduce clutter in a dialog box.

Many programs also use dialog boxes to announce messages to the user. However, avoid overusing this type of dialog box. Use a status text window to display less serious warnings.

Make sure that all dialogs are either modal to the main application or floating. You can prevent a dialog from staying hidden behind other windows if the dialog is modal or floating.

When you copy an object to another VI, you also copy the description. You may need to change the description for the new object.

Some users prefer to use the keyboard instead of a mouse. In some environments, such as a manufacturing plant, only a keyboard is available. Consider including keyboard shortcuts for VIs even if the use of a mouse is available because keyboard shortcuts add convenience to a VI.

Pay attention to the key navigation options for objects on the front panel and set the tabbing order for the objects to read left to right and top to bottom. Set the <Enter> key as the keyboard shortcut for the front panel default control, which is usually the OK button. However, if you have a multiline string control on the front panel, you might not want to use the <Enter> key as a shortcut.

If the front panel has a Cancel button, set the <Esc> key to be the keyboard shortcut. You also can use function keys as navigation buttons to move from screen to screen. If you do this, be sure to use the shortcuts consistently. Select Edit�Set Tabbing Order to arrange controls in a logical sequence when the user needs to tab between the controls. For controls that are offscreen, use the Key Navigation tab of the Properties dialog box to skip over the controls when tabbing or to hide the controls.

Also consider using the key focus property to set the focus programmatically to a specific control when the front panel opens.

If you have a reason not to follow this guideline, provide a wire label or a floating comment to explain any exceptions.

Use owned labels to label long wires. Labeling wires is useful for wires coming from shift registers and for long wires that span the entire block diagram.

Organize the block diagram and draw wires according to suggested design guidelines. You also can automatically clean up the wires on the block diagram.

Use the Align Objects and Distribute Objects pull-down menus on the toolbar to arrange objects the block diagram. When objects are aligned and distributed evenly, you can use straight wires to connect objects together. Using straight wires makes the block diagram easier to read.

The subVI icon is more helpful than the connector pane on the block diagram. The VI icon reveals the purpose of the VI. A connector pane only displays how inputs and outputs are connected. Right-click the subVI and select Visible Items. Verify that the Terminals option does not contain a checkmark.

Use the built-in LabVIEW string constants. For example, you can use an empty string as a constant to specify the data type of the elements the queue holds.

The Bundle by Name and Unbundle by Name functions reference elements of a cluster by name instead of cluster order. You can eliminate the challenge of deciphering the purpose of each data element by referencing elements of a cluster by name. You also can reorder elements or add new elements to a cluster without potentially causing a VI to break.

Otherwise, use the Bundle by Name and Unbundle by Name functions to specify the values of the cluster. If many elements differ from the default value, wrap the Unbundle by Name or Bundle by Name functions and associated values in a subVI and inline the subVI.

For large arrays that contain many elements, show only three or four elements and update the index so that the last element and first empty element are visible. Also, display the scrollbar for large arrays.

The Long Names option may be appropriate in certain instances. For example, use the Long Names option for an element if that element shares the same short name with another element. Avoid using the No Names option. The No Names option does not provide enough information for the user to understand elements or how the code functions. Apply the same reasoning for similar nodes, such as the Invoke Library Node and IP Integration Node.

For example, avoid inheriting one concrete class from an existing concrete class. Instead, create an abstract class as the common parent to both of the concrete classes.

The number of colors and patterns in the block diagram window can affect the readability of LabVIEW code. Change the wire appearance of LabVIEW class wires only if necessary to differentiate between other class wires in the block diagram window.

Best practice requires that any class containing one refnum type should only contain refnum types as elements. Although you can include a mixture of data value reference types and by-value types in a class, the mixture can demonstrate ambiguous behavior when you fork the wire on the diagram. Data value reference types refer to the original element. By-value types create copies of the original element instead of referring directly to the original. Mixing the two types can cause confusing behavior.

Avoid using parenthesis for any other purposes. In most cases, you can exclude the default value if it is the same as the default value for the given data type.

For the first style, place terminal labels to the left of the terminal for controls and to the right of the terminal for indicators.

For the second style, left-align terminal labels above the terminal. Use the style you choose consistently within a VI, a library, or a project.

Use the application font on the block diagram unless you have a specific reason to use a different font.

To test VI the documentation you create for a VI, write and revise a VI description and confirm that the description displays correctly in the Context Help window. Describe how to use the VI and any required parameter settings in the VI Description text box on the Documentation page of the VI Properties dialog box.

Check the spelling of all words in the VI Properties dialog box and on the front panel and block diagram.

The size of the block diagram window can affect the readability of LabVIEW code. Size the block diagram window no larger than the screen size. Code larger than the window is difficult to read because you must scroll through the window. If the code is too large to fit on one screen, configure the screen to scroll only in one direction to display the rest of the code. If the block diagram requires scrolling, consider using subVIs.

Use a type definition when you use the same unique control in more than one location or when you have a very large data structure passing between several subVIs.

By using a type definition control, LabVIEW automatically propagates changes to the control or the data structure throughout all the VIs and subVIs.

If you use a Boolean control for two options, consider using an enumerated type control instead to potentially expand options in the future.

Use an enumerated type over a ring control.

If you must use a ring control, configure it as a strict type definition so that all menu items update for each use. If you do create a strict type definition, extend the size beyond the longest words to allow for easier expansion of future options. Ring controls allow you to easily interact with front panels if you want to programmatically change the string labels. You also may want to use a ring control instead of a Boolean control. If you change the control to include more than two options, you can easily add options to a ring control.

You cannot programmatically change the string labels in an enumerated type control at run time because the string labels are a part of the data type.

When you use enumerated type controls, always make a type definition of the control. Creating type definitions prevents you from needing to rewrite the code each time you add or remove an item from an enumerated type control.

Enumerated type controls also help make block diagram code easier to read because when you wire an enumerated type control to a Case structure, the string labels appear in the selector label of the Case structure.

If you add a new element to an enum wired to the default case of a Case structure, the code executes the default case and can cause an error.

If possible, pass the reference wire in place of using named queues and notifiers. If you must use named queues and named notifiers, avoid name collisions.

You can use subVIs for opening and closing references. If you use subVIS to open or close a reference, pair the subVIs up. Use VI names and icons that reflect these pairings. For example, use pairs of words such as "Open" and "Close" or "Obtain" and "Release."

Use a path control or indicator to specify the location of a file or directory. Unlike strings, path controls and indicators format paths using the standard syntax for the platform you use.

Set the browse options appropriately for the Browse button of path controls. For example, if you need to select a directory, select the Folders only and Existing only options on the Browse Options page of the Properties dialog box.

Use a path constant and the path data type to supply a constant path value to the block diagram. The path constant and data type use the platform-specific notation for paths, unlike the string constant and data type.

When possible, either use relative paths and define a root path in your code or determine the root path dynamically at run-time based on system settings or the application location. Ensure that relative file paths work for the operating system on which the code is intended to run.

Absolute paths can cause problems when you build an application or run the VI on a different computer. If you must use an absolute path, ensure that you include code to both test that the path exists and to create a path if one does not exist.

You can use synchronization techniques such as queues, data value references, and semaphores to prevent race conditions. You also can use functional global variables to prevent race conditions if the functional global variable protects a critical section containing actions that modify data. If a functional global variable protects sections containing actions that only read and write data, you cannot use the functional global variable to prevent race conditions.

For example, if you create an API, consider returning an error for unsupported inputs. If you create a user interface, configure the input ranges of controls.

Use a shift register if necessary to pass a value through the loop in this situation. If you wire a value or a reference to pass through a For Loop, use shift registers instead of tunnels.

If possible, avoid using VIs that only execute properly on a specific platform. Instead, place platform specific functionality inside of a conditional disable structure specific to a target.

VIs that contain Call Library Function Nodes are platform specific. VIs that call shared libraries using a Call Library Function Node are platform dependent and only work on different platforms if you have a corresponding library for each platform. If you move a VI that contains a Call Library Function Node to another platform, you must update the node to specify the shared library compiled for the new platform.

You also can use the Conditional Disable structure to configure platform-specific code. Configure these VIs as source only to increase compatibility with source control.

Avoid using arbitrary timing delays and assuming that important events execute during those delays. Also, avoid proceeding without verifying that a relevant event occurred. If you must use a delay, provide a comment about how you determined the duration of the delay.

Carefully consider every place you report a potential error inside the code. Add comments to explain any potentially confusing decisions about error placement.

Use a consistent error handling strategy. Make sure the program can deal with all error conditions and invalid values. Determine the actions for errors, such as log, terminate, and notify user.

When passing errors through loops, use shift registers instead of tunnels to maintain warnings. Give the first errors priority when merging errors unless there is a specific reason for not doing so.

Make exceptions for code that should execute even upon encountering an incoming error or for VIs that need performance optimization in the No Error case. Use VI documentation and/or comments to document exceptions.

By default, While Loops execute as quickly as possible and use all available CPU resources during execution. You can use a blocking mechanism, such as a Wait function or timeout value, to make sure a While Loop executes only as often as needed to preserve system resources.

Avoid polling front panel controls when you can use a Value Change event in an Event structure more appropriately. Avoid using time consuming code inside of the Event structure. Consider using something similar to producer-consumer pattern in the application. Place the control terminal for a Value Change event configured for a control in the Value Change event case.

The following illustration shows a situation in which you can acceptably place the control terminal as a stop button outside the event structure.

Avoid using the default icon or a blank icon. Design each new icon as distinct and different from each existing icon. The icon represents the VI on a palette and a block diagram. Well-designed icons give you a better understanding of the subVI without requiring excessive documentation.

Include error in and error out clusters in all subVIs, even if the subVI does not process errors, because error in and error out clusters help control execution flow. If a subVI has an incoming error, you can use a Case structure to send the error through the VI without executing any of the subVI code.

Maintain a consistent connector pane pattern with a library, project, or development team. Avoid using connector panes with more than 16 terminals. Use the 4x2x2x4 pattern if you work frequently with core LabVIEW VIs. Use the 5x2x2x2x5 pattern if you work frequently with libraries that use this style, such as NI-DAQmx or LabVIEW FPGA VIs.

The Required, Recommended, Optional setting for connector pane terminals affects the appearance of the inputs and outputs in the Context Help window and prevents users from neglecting to wire subVI connections. Use the Required setting for inputs that users must wire for the subVI to run properly. Use the Optional setting for inputs that have default values that work for the subVI most of the time. The VI stills functions you leave these inputs unwired.

• Use the icons in the LabVIEW libraries as prototypes. When you do not include a picture for an icon, you can use text. If you localize the application, also localize the text on the icon. Select a user friendly font and font size, such as 8 point Small Font in all caps.
• Create a unified icon style for related VIs to help users visually understand which subVIs are associated with the top-level VI.
• Always create standard size (32 � 32 pixel) icons. VIs with smaller icons can be awkward to select and wire because of the variation in size.
• Avoid using colloquialisms in icons. Colloquialisms are difficult to translate. Also, consider cultural and language difference when you create icons. Certain pictures may not translate well. For example, avoid representing a data logging VI with a picture of a tree branch or a lumberjack.

When naming VIs, LLBs, and directories, avoid using characters not accepted by all file systems, such as backslash (\), slash (/), colon (:), and tilde (~). Most operating systems accept long descriptive filenames up to 255 characters.

If you make backup copies of files, save them in a directory outside of where LabVIEW typically searches to prevent LabVIEW from loading these file copies into memory when you open development VIs.

Right-click the project root in the Project Explorer window and select Find Items with No Callers from the shortcut menu to display the Find Items with No Callers dialog box. This dialog box identifies all the items you can remove.

Ensure processor usage does not stay high long enough to cause unacceptable thread starvation when a thread does not get time to execute. Verify that memory usage does not grow continually and that a plan exists to recover in case memory usage does grow continuously.

Localized error handling in FPGAs typically results in lower FPGA resource utilization because the error cluster in FPGA consists of 33 bits, one bit for status and 32 for the error code. You can often reduce 33 bits down to one.

Also monitor the timeout output of target-scoped FIFOs unless you either do not care if a timeout occurs or are certain a timeout will never occur. To handle the length of timeouts, either latch the output and notify the host that the FPGA should be restarted to ensure data integrity or use a handshaking protocol to handle resending data.

• Consider using the Configure method to set an appropriate host-side buffer. Avoid using large FPGA size buffers when possible to preserve block RAM.
• Set the DMA Read timeout to 0.
• Read a fixed-size number of elements (a multiple of the number of data channels).
• Wait until the buffer is full before reading elements.