Style Guide

The following guidelines are provided as a reference for LabVIEW development. Individuals and organizations are encouraged to cater these to best serve their needs and preferences.

Organization and Names of Files

The following guidance is applicable to all the items and artifacts that are contained within a LabVIEW Project, including VIs and containers such as Projects, Libraries, and Classes.

Organize all files logically

You should organize directories and files so that someone with a reasonable skill level is able to navigate the directory structure.

If you are consistently working on similar projects, you may want to come up with standards for your projects. The authors of this Guide have seen several different and reasonable directory organizations that were appropriate for different projects, which is why this Guide isn't detailed on this topic.

Naming Files and Directories

Choose names so they are easy to read and describe the purpose of the file or directory

- Create names that describe the purpose of the file or directory. - Use full words except where an abbreviation is well known by the intended audience, such as "USB Port" for "Universal Serial Bus Port". - Use book title case with single space characters between words. - You may use dashes in situations where dashes are ordinarily used, such as for “Real-Time”. - Make sure those names work in all relevant platforms.

Details: Refer to Appendix A: Book Title Case for definition and examples.

Windows file path length limitation

When coming up with file and directory names, keep in mind the Windows file path length limitation of 260 characters.

Avoid special characters in file names

For greatest cross-platform compatibility and to simplify reading of file names, avoid the use of special characters in file names such as:

• File separators like : (colon) / (forward-slash) \ (backward-slash).
• Symbols like ¢™$®.
• Punctuation marks, parentheses, quotation marks, brackets, and operators like . , [ ] { } ( ) ! ; " ' * ? < > |.
• White space characters such as tabs, new lines, and embedded returns. Note: Spaces are acceptable for most applications.

Do not use camel-case, Pascal-case, or underscore characters for separation of adjacent words

Bad: - GRTC.lvproject - GenRTCntrl.lvproj

Good: - GenericRealTimeControl.lvproj - Generic Real-Time Control.lvproj - ExitAllOnErr.vi - Exit All on Error.vi

Use names of control VIs as labels

Use names of control VIs as labels for corresponding controls. For example, use the label alarm boolean as the label in Alarm Boolean.ctl.

Name polymorphic VI instances

Name polymorphic VI instances by using space-dash-space between the poly VI name and the specific instance designation. For example, if the poly VI is called Read My Special File.vi, then an instance VI may be called Read My Special File - I32.vi.

File and Directory Names for Examples, Templates, and Sample Projects

This subsection applies to the examples, templates, and sample projects installed in relevant directories within the LabVIEW directory structure.

Add a prefix to all example names when developing for a specific driver or addon

Use the form `<Short Product Name><space><Example Name>`. E.g., NI-DAQmx Voltage - Continuous Input.vi.

Avoid deeply nested file folders

Ensure that none of your project’s file folders on disk are too deeply nested. If the user’s project contains a file with a path that exceeds 260 characters in length (for Windows), the project copy will fail. Aim for having a maximum path length of less than 150 characters so there is plenty of room to account for a user saving their project in a deeply-nested path.

Name your .lvproj file the same as the folder that contains it

For templates and sample projects, name your .lvproj file the same as the folder that contains it, e.g., the “PC USRP-RIO Streaming” template folder contains “PC USRP-RIO Streaming.lvproj”.

Project Organization

Place the top-level VIs for the project directly under appropriate targets

Place the top-level VIs directly under the appropriate targets. Because you cannot mark a VI as a top-level VI, placing the top-level VIs under the corresponding target helps clarify which VIs are top-level.

Organize VIs in a hierarchical directory

Organize VIs in a hierarchical directory with easily accessible top-level VIs and subVIs in subdirectories. Limit the number and level of directories in a project.

Place all VIs in libraries, classes, or virtual folders

Avoid using auto-populating folders unless you have a good reason to use them.

Remove all unused files

Details: - Remove all unused files both from the applicable projects/libraries and from the disk.

Tip: - 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.

Libraries

Consider using virtual folders to delineate between public and private members of a library

(VI Analyzer) Consider using virtual folders to delineate between public and private members of a library.

Place APIs in a library

Place APIs in a library to improve organization.

Mark non-API VIs as private

Mark any VIs in a library as private if they are not part of the API.

LabVIEW Classes

Name all classes as nouns

Example: - Name an example class Waveform Reader.lvclass rather than Reads Waveforms.lvclass.

Name all member VIs of a LabVIEW class as verbs

Example: - Name an example member VI Read Value.vi rather than Value.vi.

Avoid including the name of the class in VI names

Example: - If we have a class Circle and it needs a VI to return the area, this VI should just be called Calculate Area as opposed to Calculate Circle Area or Circle Calculate Area. Note that LabVIEW provides a namespace for VIs in a library such that it is considered as Circle: Calculate Area.

Use "Read" for VIs that read data

Use the word "Read" to begin the name of any VI that strictly reads data from the private data of a class. Avoid using the word "Get" or any synonym of "Get."

Use "Write" for VIs that bundle data into the private data

Use the word "Write" to begin the name of any VI that strictly bundles data into the private data of a class. Avoid using the word "Set" or any synonym of "Set."

Use Book Title Case for class virtual folders and VI names

Use Book Title Case for all class virtual folders and VI names.

Details: - When auto-created by LV, the class property virtual folder name and the class property VI names may initially match the case of the control label in the class control. Since labels should follow the label guidelines listed in section 3.1.8, you may need to change the class property virtual folder and VI names to be Book Title Case. - The name of a class property virtual folder is used as the name in a class property node. - Because this is auto-generated by LV and may be tedious to change, this guideline is a recommendation at this time. - A LabVIEW Developer tool may be created that will correct the auto-generated virtual folder and VI names to match these guidelines.

Monitor Size, Window Size, and Window Placement

Code should look good on a 1536 x 824 monitor

Write code so that it looks good on a monitor with 1536 x 824 pixels for most individual file windows, or the target monitor size if designing a UI front panel.

Details: - If you have a computer running Windows 10, 1536 x 824 pixels corresponds to 1920 x 1080 pixel resolution with 125% scaling. These are often default settings on a 15" laptop. - With properly configured LabVIEW.ini tokens you can use the Arrange VI Window Quick Drop (Ctrl-Space, Ctrl-F) to make sure your VI front panel and block diagram windows comply with this guideline. - VIWin.DisplayWorkspaceRight=1536 - VIWin.DisplayWorkspaceBottom=824

Save files with minimal white space

Save files so all relevant content that can be shown is shown without showing a lot of extraneous white space.

Position window near the upper-left corner of the monitor

Save files so the upper left corner of the window is close to the upper left corner of the monitor.

VI Window Considerations

Size the windows so the entire toolbar fits

(VI Analyzer) Size the windows so the entire toolbar fits.

Tip: - Use front panel cleanup to comply with this guideline for front panels. Use Arrange VI Window Quick Drop (Ctrl-Space, Ctrl-F) to comply with this guideline for block diagrams.

Size front panels and block diagram windows appropriately

Size the front panel and block diagram windows reasonably for the content and never full-screen.

Tip: - Use Arrange VI Window Quick Drop (Ctrl-Space, Ctrl-F) to comply with this guideline.

Consider sizing panels with tall type definitions

If a front panel contains a tall type definition cluster, consider sizing the panel to fit existing regular controls and include part of the type definition.

Include wide type definition clusters in the panel

If a front panel contains a wide type definition cluster, consider including the cluster below the visible screen and a note indicating that the user can scroll down to see it.

Entire block diagram should fit on the monitor

The entire block diagram of a VI should fit on the monitor.

Details: - If this guideline is impossible to comply with, write the block diagram so you can read it scrolling in only one direction.

VI, Library, and Class Interfaces

Front Panel

Set reasonable default values for controls

Set reasonable default values for controls. Use data type defaults for indicators.

Avoid overlapping labels and displays

(VI Analyzer) Avoid overlapping the labels, digital displays, or other parts of controls and indicators. - Allow for extra space between controls and indicators to account for font changes on different platforms, and for Windows scale and layout settings. - Overlapped controls and indicators slow down screen updates and can make the control or indicator flicker.

Use path controls and indicators

Use path controls and indicators instead of string controls and indicators to specify the location of files or directories.

Rationale: - Unlike strings, path controls format paths using the standard syntax for the platform you use.

Set appropriate browse options for path controls

When using path controls, set the browse options appropriately. For example, if a path control is intended for existing directories, select the Folders only and Existing only options on the Browse Options page of the Properties dialog box.

GUI VI Front Panels

Note: In this context, a GUI is a VI front panel that is used as a visual part of a UX, for example the visual piece of a LabVIEW-built application or the visual piece of a plug-in to a framework. As a counter-example, VIs that are parts of APIs are not considered GUI VIs, even if they happen to go on palettes.

Minimize the use of colors

Minimize the use of colors. Use colors logically and consistently.

Hide the toolbar

Hide the toolbar.

Use consistent control styles

Use one consistent style for all controls. Use system controls when possible.

Customize appearance with strict type definitions

Use custom controls or strict type definition controls to customize the appearance of a control. Use strict type definition controls only to preserve the exact appearance of a control in each location of use.

Use standard fonts

(VI Analyzer) Use the standard application, system, and dialog fonts for all user interfaces in the application.

Details: - 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.

Configure numeric inputs to coerce values

Configure numeric inputs to coerce values to the valid data range if applicable.

Arrange controls logically

Arrange controls from top left to bottom right.

Details: - 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.

Organize UI elements with logical layout

Organize UI elements using proximity, alignment, decorations, and UI features such as tab controls and subpanels.

Configure the front panel to fit the monitor

Configure the front panel to fit the monitor resolution used in the application.

Details: - Monitor resolution used in the deployed system may be different from monitors used for development.

Use labels for controls and indicators

Use labels to describe the function of controls and indicators. Limit caption use to controls and indicators that require more information than the label conveys or when you need the ability to change the display text of a control programmatically.

Details: - Use captions for descriptive text if the label is insufficient.

Set intuitive keyboard shortcuts

Set up intuitive keyboard shortcuts and tabbing order for controls.

Details: - Some users prefer to use the keyboard instead of a mouse. Consider including keyboard shortcuts for VIs, even if the use of a mouse is available. Set the tabbing order for controls from left to right and top to bottom. Use the <Enter> key for the default control and the <Esc> key for the Cancel button.

Write descriptions and tip strips

Write descriptions and create tip strips for UI front panels and controls to describe the purpose of an object and give users instructions for using the object.

Dialog Front Panels

Use system control style

(VI Analyzer) Use the system control style when possible to ensure that dialogs look consistent with the operating system.

Do not use scroll bars on entire front panels

Do not show scroll bars on the entire front panel windows. Design the dialog box to display all information. Use scroll bars on individual controls and indicators as appropriate.

Tip: - Set the VI Window Appearance to Dialog through File > VI Properties.

Provide meaningful window titles

Provide a meaningful window title that explains the purpose of the dialog.

Avoid default menus

If the dialog has menus, only use menus that are specific to the dialog window. Avoid using default menus.

Limit dialog box use

Limit dialog box use to critical user interactions. Avoid overusing dialogs.

Ensure dialogs are modal or floating

Make sure that all dialogs are either modal to the main application or floating.

Use the system panel background color

Use the system panel background color for dialog user interfaces to maintain consistency.

Center the dialog on the main monitor

Center the dialog on the main monitor.

Non-GUI VI Front Panels

Use default colors for UI elements

(VI Analyzer) Use the default colors for all UI elements of the front panel.

Arrange controls and indicators relative to connector pane terminals

(VI Analyzer) Arrange controls and indicators relative to corresponding connector pane terminals.

Tip: - Use Arrange VI Window Quick Drop (Ctrl-Space, Ctrl-F) to arrange the panel objects.

Group related data into clusters

Consider grouping related input and output data into clusters. Make the cluster a type definition.

Use Modern style controls

Use Modern style controls, except if you use a type definition from a dependency that isn’t a Modern style control.

Use buttons for Boolean controls and LEDs for Boolean indicators

Make sure controls look like controls and indicators look like indicators. For example, use buttons for Boolean controls and LEDs for Boolean indicators, except if you use a type definition.

Use labels, not captions, unless localization is required

Use control and indicator captions only if you need to localize non-GUI VIs. Otherwise, only use labels.

Control and Indicator Labels/Captions

Choose descriptive names

Choose names so they are easy to read and describe the purpose of the control or indicator.

- Create names that describe the purpose of the control or indicator. - Use full words except where an abbreviation is well known by the intended audience, such as "USB Port" for "Universal Serial Bus Port". - In GUI VIs, use Book Title Case. - In non-GUI VIs, use all lowercase characters except for proper nouns and common uppercase abbreviations. - Use single space characters between words. - You may use dashes in situations where dashes are ordinarily used, such as for "Real-Time." - Make sure those names work on all relevant platforms.

Details: - Refer to Appendix A: Book Title Case for definition and examples. - In this context, a GUI is a VI front panel that is used as a visual part of a UX, for example, the visual piece of a LabVIEW-built application or the visual piece of a plug-in to a framework. As a counter-example, VIs that are parts of APIs are not considered GUI VIs, even if they happen to go on palettes.

Avoid duplicate labels

(VI Analyzer) Avoid using duplicate labels.

Add "in" and "out" to input/output pairs

If a VI contains an input and output pair, add a suffix of "in" to the control label and a suffix of "out" to the indicator label. For example, if a VI includes an input called object in, name the corresponding output object out.

Label error inputs and outputs as "error in" and "error out"

If a VI has an error input or an error output, label them as "error in" and "error out" exactly as shown, unless there is a specific reason not to.

Details: - There is no value in including the default value ("no error") because you never want a different default value for the error input.

Use parenthesis in labels only for units

Use parenthesis in labels only to document units of a control or indicator when it makes sense to do so.

Details: - Avoid using parenthesis for any other purposes. - You should not include the default value in the label in parenthesis.

Use SI units

When including units in a label, use units approved and documented in The International System of Units.

Details: - Refer to Appendix B: The International System of Units for a list of conventional units.

Use "Size to Text" for labels

Use Size to Text for labels so the text rectangle automatically resizes to accommodate the text you enter. By default, Size to Text is enabled for one line of text.

Details: - The three standard fonts (application, system, and dialog) vary depending on the platform. 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 via the label's shortcut menu.

Use the default Application font for labels

Use the default Application font with all default cosmetic settings unless you have a good reason not to.

Use transparent background color for labels

(VI Analyzer) Use transparent background color for labels.

Free Labels on Front Panels

Avoid the use of free labels on front panels

Avoid the use of free labels on front panels except where particularly useful.

Example Exceptions: - VI Analyzer template front panels contain useful free labels instructing you what not to change about the controls and indicators. - Certain globals used as constants contain useful free labels reminding you to save changes to control values as default values. - Some example programs contain useful instructions on front panels.

Use carriage returns only to separate paragraphs

(VI Analyzer) Use carriage returns in free labels only to separate paragraphs.

Use Size to Text for single-line labels

(VI Analyzer) If a free label occupies a single line, use Size to Text. Size free labels with multiple lines so that all the text is visible and provide extra space at the bottom of a free label to account for font size changes across platforms.

Use the standard application font for free labels

Use the standard application font for free labels unless you have good reasons not to do so.

Classes and Property Nodes

Support Property Node syntax for data accessors

Consider supporting the syntax of Property Nodes for data accessor VIs. However, accessors that use Property Node syntax require error terminals and take more time to execute than data accessor VIs without error terminals. Evaluate and choose appropriately for each class.

VI Description

Describe what the VI does in the VI Description text box

For each VI intended to be used by others, such as API VIs and examples, describe what the VI does in the VI Description text box.

VI Connector Pane

Consider using the 4x2x2x4 conpane for all VIs

(VI Analyzer) Consider using the 4x2x2x4 conpane for all VIs. A denser 5x3x3x5 conpane may be used on rare occasions. Possible reasons for this include situations where no reasonable clustering is possible or where it creates problems for the FPGA compiler.

Use left terminals for controls and right terminals for indicators

Use the left terminals for controls and right terminals for indicators. When using the top and bottom terminals, place all controls to the left of indicators.

Place related controls and indicators at the same relative position

Place related controls and indicators at the same relative position on the connector pane. For example, if you assign a data in control to the top left terminal, assign the corresponding data out indicator to the top right terminal.

Ensure consistency for similar controls across APIs

If a control or indicator serves the same function throughout an API, name the control or indicator consistently and place it in the same position throughout all API connector panes.

Place paths, references, and classes in the top corners

(VI Analyzer) Place paths, references, and LabVIEW Classes in the top corners.

Place error terminals at the bottom corners

(VI Analyzer) Assign error in and error out terminals to the corresponding bottom left and right terminals.

Preserve empty terminals for future expansion

(VI Analyzer) Preserve empty terminals on the connector pane to allow for future expansion.

Set required terminals for must-wire inputs

Configure input terminals for parameters that must be wired for the VI to function as Required.

Set recommended terminals for inputs with good defaults

Configure input terminals that have good default values as Recommended. If you are not sure whether an input should be required or not, make it Required.

VI, Library, and Class Icons

Use glyphs for high-visibility VIs

Use glyphs in icons for VIs that will have high visibility, such as APIs for software products. Use text in icons otherwise.

Rationale: - The effort required to create good glyph-based icons is rarely justified for VIs with limited audience.

Always create standard size (32x32 pixel) icons

Always create standard size (32x32 pixel) icons.

Exceptions: - In very rare cases it may be appropriate to have a shorter icon. For example, if you use an enumeration with names of hardware registers, you may want to use a short icon for a commonly used register-name-to-register-address subVI to preserve block diagram space in subVI call locations.

Use glyphs from the Glyphs tab in the icon editor when applicable

Use glyphs from the Glyphs tab in the icon editor when applicable.

Avoid using colloquialisms in icons

Avoid using colloquialisms in icons because they may not work across cultures and languages. For example, avoid representing a data logging VI with a picture of a tree branch or a lumberjack. On the other hand, a pencil is generally understood as a utensil for writing.

Use standard text settings for icons

Use the following font settings for the text used in icons: - Font: Small Fonts - Alignment: Center - Size: 9 - Center text vertically: Checked - Capitalize text: Checked - Color: Black, with a possible exception for the library layer set forth below

Use text that matches all or part of the VI name

Use text that matches all or part of the VI name in the icon.

Limit the text to three lines with a library or class banner

Limit the text to three lines if a library or class icon banner is included or to four lines otherwise.

External links

• LabVIEW Development Guidelines (PDF)
• The LabVIEW Style Book (Amazon.com)