Company Events Academic Community Support Solutions Products & Services Contact NI MyNI

LabVIEW Style Checklist

LabVIEW 2014 Help

Edition Date: June 2014

Part Number: 371361L-01

»View Product Info
Download Help (Windows Only)

Use the following checklists to help you maintain consistent style and quality. You can customize these checklists to fit the specifications of your application.

Note  The LabVIEW VI Analyzer Toolkit provides tests that check VIs interactively or programmatically for style, efficiency, and other aspects of LabVIEW programming. Refer to the National Instruments website to learn more about this LabVIEW toolkit.

Front Panel Checklist

Give controls meaningful labels and captions.


The name of a control or indicator should describe its function. 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. For example, when you label a ring control or slide control that has options for volts, ohms, or amperes, select an intuitive name for the control. A caption such as "Select units for display" is a better choice than "V/O/A". Use Property Nodes to change captions programmatically.

Use consistent capitalization, and include default values and unit information in label names. For example, if a control sets the high limit temperature and has a default value of 75 °F, name the control high limit temperature (75 degF). If you will use the VI with the control on multiple platforms, avoid using special characters in control names. For example, use degF instead of °F, because the ° symbol might not display correctly on other platforms.

For Boolean controls, use the name to give an indication of which state (TRUE or FALSE) corresponds to the function (for example, ON) and 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. For example, use free labels like Cancel, Reset, and Initialize that describe the action taken.

The Context Help window displays labels as part of the connector pane. If the default value is essential information, place the value in parentheses next to the name in the label. Include the units of the value if applicable.

Write descriptions and create tip strips for controls and indicators, including array, cluster, and refnum elements.


To describe the purpose of the object and to give users instructions for using the object, create descriptions and tip strips for the object. Remember that if you copy the object to another VI, you also copy the description. You might need to change the description for the new object.

Set controls with reasonable default values.


A VI should not fail when run with default values. Do not set default values of indicators like graphs, arrays, and strings without a good reason because that wastes disk space when saving the VI.

Use default values intelligently. In the case of many File I/O VIs and functions, such as the Write to Spreadsheet File VI, the default is an empty path that forces the VI to display a file dialog box. This can save the use of a Boolean switch in many cases.

You can handle difficult situations programmatically. Many GPIB instruments limit the permissible settings of one control based on the settings of another. For example, a voltmeter might permit a range setting of 2,000 V for DC but only 1,000 V for AC. If the affected controls like Range and Mode reside in the same VI, place the interlock logic there.

Configure numeric inputs with data ranges.


Expect the user to supply invalid values for numeric controls. Right-click the control and select Data Entry to set the control item to coerce invalid values into a desired range: Minimum, Maximum, and Increment.

Ensure the background of control and indicator labels are transparent.
Use standard, consistent fonts—application, system, and dialog—throughout all front panels.


Limit the VI to the three standard fonts (application, system, and dialog) unless you have a specific reason to use a different font. For example, monospace fonts, which are fonts that are proportionally spaced, are useful for string controls and indicators where the number of characters is critical.

Use Size to Text for all text for portability and add carriage returns if necessary.


The actual font used for the three standard fonts (application, system, and dialog) varies depending on the platform. For example, when working on Windows, preferences and video driver settings affect the size of the fonts. Text might appear larger or smaller on different systems, depending on these factors. To compensate for this, allow extra space for larger fonts and enable the Size to Text option on the shortcut menu.

Check for consistent placement of control labels and allow extra space between controls to prevent labels from overlapping objects because of font changes on multiple platforms.


For example, if a label is to the left of an object, justify the label to the right and leave some space to the left of the text. If you center a label over or under an object, center the text of that label as well. Fonts are the least portable aspect of the front panel so always test them on all target platforms.

Do not overlap controls with other controls, with their label, digital display, or other objects unless you want to achieve a special effect. Overlapped controls slow down screen updates and can make the control or indicator flicker.
Group and arrange controls logically and attractively.


Consider the arrangement of controls on front panels. Keep front panels simple to avoid confusing the user. For example, you can use menus to help reduce clutter. For top-level VIs that users see, 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.

Use the Align Objects and the Distribute Objects pull-down menus to create a uniform layout.

Use decorations, such as a Raised Box or Horizontal Smooth Box, to visually group objects with related functions. Use clusters to group related data. Do not use clusters for aesthetic purposes only.

Use color logically, sparingly, and consistently, if at all.


Color can distract the user from important information. For instance, a yellow, green, or bright orange background makes it difficult to see a red danger light. Another problem is that some platforms do not have as many colors available. Use a minimal number of colors, emphasizing black, white, and gray. The following are some simple guidelines for using color:

  • Never use color as the sole indicator of device state. People with some degree of color-blindness can have problems detecting the change. Also, multi-plot graphs and charts can lose meaning when displayed in black and white. Use lines for plot styles in addition to color.
  • Consider coloring the pane backgrounds on the front panel background and objects of user interface VIs with the system colors, or symbolic colors, in the color picker. System colors adapt the appearance of the front panel to the system colors of any computer that runs the VI.
  • Use light gray, white, or pastel colors for backgrounds. The first row of colors in the color picker contains less harsh colors suitable for front panel backgrounds and normal controls. The second row of colors in the color picker contains brighter colors you can use to highlight important controls. Select bright, highlighting colors only when the item is important, such as an error notification.
  • Always check the VI for consistency on other platforms.
Use path controls instead of string controls to specify the location of files or directories.


When specifying the location of a file or directory, use a path control or indicator. Path controls and indicators work similarly to strings, but LabVIEW formats paths using the standard syntax for the platform you are using. Set the browse options appropriately for the Browse button of path controls. For example, if the user needs to select a directory, select the Folders only and Existing only options on the Browse Options page of the Properties dialog box.

Provide a stop button if necessary. Do not use the Abort button to stop a VI. Hide the Abort button.


The Abort Execution button stops the VI immediately, before the VI finishes the current iteration. Aborting a VI that uses external resources, such as external hardware, might leave the resources in an unknown state by not resetting or releasing them properly.

Use ring controls and enumerated type controls where appropriate. If you are using a Boolean control for two options, consider using an enumerated type control instead to allow for future expansion of options.


Ring controls are useful for front panels the user interacts with where you want to programmatically change the string labels. You might want to use a ring control instead of a Boolean control because if you decide to change the control to include more than two options, you can add options easily to a ring control.

You cannot change the string labels in an enumerated type control programmatically at run time because the string labels are a part of the data type. When using 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 are useful for making 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.

Use type definitions for common controls, especially for enumerated type controls and data structures.
Label custom controls with the same name as the file. For example, Alarm Boolean.ctl has the default name Alarm Boolean.
Make sure all the controls on the front panel are of the same style. For example, do not use both classic and modern controls on the same front panel.
Use Property Nodes to give the user more feedback on the front panel and to make the VI easier to use.


The following are examples of how Property Nodes can enhance ease of use in an application or VI:

  • Set the text focus to the main, most commonly used control.
  • Disable or hide controls that are not currently relevant or valid.
  • Guide the user through steps by highlighting controls.
  • Change colors to bring attention to error conditions.

You can modify front panel objects in subVIs using control references. Use the control refnum controls to pass front panel object references to other VIs. After you pass a control reference to a subVI, use Property Nodes and Invoke Nodes to read and write properties and invoke methods of the referenced front panel object. Control references reduce the clutter on the block diagram.

Use imported graphics to enhance the front panel.


You can import graphics and text objects to use as front panel backgrounds, items in picture rings, and parts of custom controls and indicators.

Check how the imported graphics look when you load the VI on another platform. For example, a Macintosh PICT file that has an irregular shape might convert to a rectangular bitmap with a white background on Windows or Linux.

One disadvantage of using imported graphics is that they slow down screen updates. Make sure you do not place indicators and controls on top of a graphic object so that LabVIEW does not have to redraw the object each time the indicator updates. If you must use a large background picture with controls on top of it, divide the picture into several smaller objects and import them separately because large graphics usually take longer to draw than small ones.

Set up key navigation and keyboard shortcuts for controls and indicators on the front panel.


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.

Configure the front panel to fit on the screens of most users.


Front panels need to fit on a monitor that is the standard resolution for most intended users. Make the window as small as possible without crowding controls or sacrificing a clear layout. If the VIs are for in-house use and everyone is using high-resolution display settings, you can design large front panels. If you are doing commercial development, keep in mind that some displays have a limited resolution, especially LCD displays and touchscreens.

Front panels should open in the upper-left corner of the screen for the convenience of users with small screens. Place sets of VIs that are often opened together so the user can see at least a small part of each. Place front panels that open automatically in the center of the screen. Centering the front panels makes the VI easier to read for users on monitors of various sizes. Use the VI Properties dialog box to customize the window appearance and size.

Create dialog boxes to help users input data.


Dialog boxes are an effective way to gather settings and configuration information from the user. Use system controls in the dialog box you create to prompt users to configure and set the options for the dialog box. Consider using tab controls, which group front panel controls and indicators in a smaller area, to reduce clutter in a dialog box.

Many programs also use dialog boxes to announce messages to the user, but quite often this type of dialog box is overused. Use a status text window to display less serious warnings.

Block Diagram Checklist

Avoid creating extremely large block diagrams. Limit the scrolling necessary to see the entire block diagram to one direction.


The size of the block diagram window can affect how readable LabVIEW code is to others. Make the block diagram window no larger than the screen size. Code that is larger than the window is hard to read because it forces users to scroll through the window. If the code is too large to fit on one screen, make sure the user has to scroll only in one direction to view the rest of the code. If the block diagram requires scrolling, consider using subVIs.

Use labels to describe code on the block diagram.


Developers who maintain and modify VIs need good documentation on the block diagram. Without it, modifying the code is more time consuming and error prone. Use the following suggestions to describe code on the block diagram.

  • Use labels on Call Library Function Nodes to specify what function the node is calling and the path to the library the node calls.
  • Use free labels to document algorithms that you use on the block diagrams. If you use an algorithm from a book or other reference, provide the reference information.
  • Use subdiagram labels to describe the code contained within structures.
  • Do not show labels on function and subVI calls because they tend to be large and unwieldy. A developer looking at the block diagram can find the name of a function or subVI by using the Context Help window.
  • Use hashtags (#) in block diagram comments to manage unfinished tasks.
Avoid creating excessive wire patterns and colors if you change the wire appearance of a LabVIEW class wire.


The number of colors and patterns in the block diagram window can affect how readable LabVIEW code is to others. Change the wire appearance of LabVIEW class wires only when it is necessary to differentiate between other class wires in the block diagram window.

Use the standard application font in free labels on all block diagrams.


Limit the VI to the application font on the block diagram unless you have a specific reason to use a different font.
Use Size to Text for all text for portability and add carriage returns if necessary.


The actual font used for the three standard fonts (application, system, and dialog) varies depending on the platform. For example, when working on Windows, preferences and video driver settings affect the size of the fonts. Text might appear larger or smaller on different systems, depending on these factors. To compensate for this, allow extra space for larger fonts and enable the Size to Text option on the shortcut menu.
Make sure data flows from left to right and wires enter from the left and exit to the right.


Although the positions of program elements do not determine execution order, avoid wiring from right to left. Only wires and structures determine execution order.

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

Add as few bends in the wires as possible and keep the wires short. Avoid creating wires with long complicated paths because long wires are confusing to follow.

To reroute all existing wires and rearrange objects on the block diagram automatically, select Edit»Clean Up Diagram. You also can clean up the block diagram by clicking the Clean Up Diagram button on the block diagram toolbar or pressing the <Ctrl–U> keys. (Mac OS X) Press the <Command–U> keys. (Linux) Press the <Alt–U> keys.

Align and distribute functions, terminals, and constants.


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

Avoid placing block diagram objects, such as subVIs or structures, on top of wires, and do not wire behind objects.


Avoid placing any wires under block diagram objects because LabVIEW can hide some segments of the resulting wire. Draw wires so that you can clearly see if a wire correctly connects to a terminal. Delete any extraneous wires. Do not wire through structures if the data in the wire is not used in the structure.

Use path constants instead of string constants to specify the location of files or directories.


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.

Make sure the program can deal with error conditions and invalid values.
Use sequence structures sparingly because they hide code. If flow-through parameters are not available and you must use a sequence structure in the VI, consider using a Flat Sequence structure.


Rely on data flow rather than sequence structures to control the order of execution. With sequence structures, you break the left-to-right data flow paradigm whenever you use a sequence local variable. To help control data flow, you can use error clusters instead.

Make sure the subVI icon, rather than the connector pane, is visible on the block diagram.


The subVI icon is more helpful than the connector pane on the block diagram. Right-click the subVI and select Visible Items and make sure there is no checkmark next to the Terminals option.

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 open references to a LabVIEW object, such as an application, control, or VI, close the references by using the Close Reference function. It is good practice to close any reference you open programmatically.
Make sure the Name Format for Property Nodes and Invoke Nodes is set to Short Names to ensure the best readability of the block diagram.
Make sure control and indicator terminals on the connector pane are not inside structures on the block diagram.


When you use the VI as a subVI, LabVIEW might not access any controls or indicators that are inside structures if the diagram they are in does not execute.

Avoid using local variables when you can use a wire to transfer data. Every local variable that reads the data makes a copy of the data. Use global and local variables as sparingly as possible.


You can use global and local variables to write VIs efficiently, but use global and local variables as sparingly as possible. If you misuse or abuse global and local variables, particularly with array data types, the memory usage of the VI increases and the performance is affected.

You can encounter race conditions when reading from and writing to local or global variables in the same application. Race conditions are difficult to debug because there is no data dependency between different instances of the same local or global variable on the block diagram.

Consider using functional global variables instead of global variables. Functional global variables do not create extra copies of data and allow certain actions, such as initialize, read, write, and empty. You also can use functional global variables to avoid race conditions if the functional global variable protects a critical section containing actions that modify data.

Save the VI with the most important frame of multi-framed structures, like the Case, Event, and Stacked Sequence structures, showing.
Maximize the performance of the code on the block diagram.


When a program has large arrays or critical timing problems, you can use the following guidelines to maximize the performance of the VI.

  • Add a Wait function inside a While Loop to avoid slowing down other tasks outside of the loop. Generally, slowing down other tasks is only an issue with loops that are not very active between iterations, such as user interface loops, because LabVIEW runs the loop as quickly as possible and does not give many processor resources to other tasks.

    Add a slight delay between loop iterations with the Wait (ms) function to help the computer run outside tasks normally without affecting the operation of the loop. Typically, a delay of 50 to 100 ms is enough, but other factors in the application can affect the delay. Use the Wait Until Next ms Multiple function to time the loop iterations more precisely.
  • Force less important parallel tasks to wait using the Wait (ms) function so crucial tasks have more processor time.
  • Use an Event structure to wait for a user interface event because they do not require processor time.
  • If possible, do not build arrays using the Build Array function within a loop because the function makes repetitive calls to the LabVIEW memory manager. Instead, use auto-indexing or pre-size the array and use the Replace Array Subset function to place values in it. Similar issues exist when dealing with strings because, in memory, LabVIEW handles strings as arrays of characters.
  • Avoid using autoscaling on graphs and charts if you do not need it. Autoscaling can slow performance.
  • Choose the proper array data type to control the memory usage of the application. For example, if you have an extended-precision, floating-point array of 100,000 values, but the values stored in the array are single-precision, floating-point values, there is an inefficient use of memory. Use an array of single-precision, floating-point values to match the data type stored in the array to reduce the memory usage.
  • Display only necessary information on the front panel. Send data to indicators only if the data is different from what the indicator already displays. Frequently updating front panel indicators with new data can affect the performance of the VI especially if you are displaying large amounts of data in graphs or charts.
  • For small subVIs, subVIs within a loop, subVIs with unwired outputs, or subVIs you call only once, consider inlining the subVIs into their calling VIs to minimize subVI overhead.

VI Checklist

Organize VIs in a hierarchical directory with easily accessible top-level VIs and subVIs in subdirectories.


Organize the VIs in the file system to reflect the hierarchical nature of the software. Make top-level VIs directly accessible. Place subVIs in subdirectories and group them to reflect any modular components you have designed, such as instrument drivers, configuration utilities, and file I/O drivers. Limit the number and levels of directories you use in a project.

Avoid using absolute paths in VIs.


Using absolute paths might 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 test that the path exists and to create the path if it does not exist.

Capitalize first letters of VI names and give VIs meaningful names without special characters, such as backslash (\), slash (/), colon (:), and tilde (~).


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

Only one VI of a given name can be in memory at a time. Use project libraries to qualify the names of VIs and other LabVIEW files. LabVIEW identifies VIs by filename, so LabVIEW unintentionally might load and reference a VI because the VI has the same filename as another VI, a problem known as cross-linking. When a VI is part of a project library, LabVIEW qualifies the VI name with the project library name to avoid cross-linking. A qualified name includes the filename and the qualified name of the owning project library.

For example, if you build a VI named that includes a subVI named that library1.lvlib owns, you also can include a different subVI named that library2.lvlib owns and avoid cross-linking problems. The qualified names that LabVIEW records when you save are and respectively.

If you make backup copies of files, be sure to save them into a directory outside the normal search hierarchy so that LabVIEW does not mistakenly load them into memory when you open development VIs.

Use standard extensions (.vi, .ctl) so the operating system can distinguish files.
Write a VI description, proofread it, and confirm that it displays correctly in the Context Help window.


Describe how to use the VI and any required parameter settings in the VI Description on the Documentation page of the VI Properties dialog box.
Create a meaningful icon for every VI.


The icon represents the VI on a palette and a block diagram. When subVIs have well-designed icons, developers can gain a better understanding of the subVI without the need for excessive documentation.

Use the following suggestions when creating icons.

  • The LabVIEW libraries include well-designed icons that you can use as prototypes. When you do not have a picture for an icon, text is acceptable. If you localize the application, make sure you also localize the text on the icon. A good size and font choice for text icons is 8 point Small Fonts in all caps.
  • Create a unified icon style for related VIs to help users visually understand what subVIs are associated with the top-level VI.
  • Always create standard size (32 × 32 pixels) icons. VIs with smaller icons can be awkward to select and wire and might look strange when wired.
  • Do not use colloquialisms when making an icon because colloquialisms are difficult to translate. Users whose native language is not English might not understand a picture that does not translate well. For example, do not represent a data logging VI with a picture of a tree branch or a lumberjack.
Keep the default 4 × 2 × 2 × 4 connector pane pattern to leave extra terminals for later development.


Using the same pattern ensures that all VIs, even VIs with few inputs, line up correctly and have straight wires connecting them. Always select a connector pane pattern with more terminals than necessary. Including extra terminals in the VI allows you to add additional connectors to the VI and makes relinking to the subVI in calling VIs unnecessary.

Use a consistent connector pane layout across related VIs.


Wire inputs on the left and outputs on the right to follow the standard left-to-right data flow.

When assigning terminals, keep in mind how the VIs will be wired together. If you create a group of subVIs that you use together often, give the subVIs a consistent connector pane with common inputs in the same location to help you remember where to locate each input. If you create a subVI that produces an output another subVI uses as the input, such as references, task IDs, and error clusters, align the input and output connections to simplify the wiring patterns.

When assigning terminals as inputs and outputs, make sure to split the terminals of the connector pane consistently. If you need to use the middle four terminals of the 4 × 2 × 2 × 4, divide them either horizontally or vertically. For example, assign the inputs to the top two terminals and the outputs to the bottom two terminals or assign the inputs to the left two terminals and the outputs to the right two terminals.

Avoid using connector panes with more than 16 terminals.


Although connector pane patterns with more terminals might seem useful, they are very difficult to wire. If you need to pass more data, use clusters.

Use Required, Recommended, and Optional settings on the connector pane.


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 forgetting 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 are appropriate for the subVI most of the time.

Create test VIs that check error conditions, invalid values, and Cancel buttons. Save test VIs in a separate directory so you can reuse them. You also can use the Unit Test Framework Toolkit to perform unit testing on VIs.
Make good use of reusable, testable subVIs.
Use error in and error out clusters in all subVIs.


Include error in and error out clusters in all subVIs, even if the subVI does not process errors. error in and error out clusters are helpful for controlling 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.

If the VIs need to run on multiple platforms, avoid using VIs that are platform specific and create different versions of the VI that contain the Call Library Function Node for each platform.


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.

If applicable, load and test VIs on multiple platforms, making sure labels fit and window size and position are correct.
Review the VI for efficiency, data copying, and accuracy, especially parts without data dependency.


Use the Show Buffer Allocations window to determine where LabVIEW allocates memory.


Your Feedback! poor Poor  |  Excellent excellent   Yes No
 Document Quality? 
 Answered Your Question? 
Add Comments 1 2 3 4 5 submit