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.

External links

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