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.
= Do not include the word "example" in any file or folder names =
= 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.
For non-library VIs, use a plain transparent square with a single pixel black border For VIs that are not part of a library or class, use a plain transparent square with a single pixel black border as the base layer for the icon.
For library or class VIs, use a library layer with a black border For VIs that are part of a library or class, use a library layer and a plain transparent square with a single pixel black border as the base layers for the icon.
Use 32x9 pixel rectangles for library/class banners Use 32x9 pixel rectangles with black frames for library and class library icons. Position those rectangles at the very top of the 32x32 pixels allocated for the icons.
Tip: - Reduce the size of the default library and class icon by three vertical pixels.
Rationale: - Taking into account a pixel for the bottom border, this leaves 22 vertical pixels for individual VI icons. If you are using text with the settings specified below, and you have three lines of text, 23 vertical pixels give you two pixels of vertical spacing between the top and text, two pixels of vertical spacing between the lines, and one pixel of vertical spacing between the last line and the bottom border, which makes the text for the individual icon look reasonably good.
Limit text in the banner to a single line Limit text in the banner of the library and class icons to a single line.
Ensure contrast between front and background colors If you put text in the library or class icon banner, make sure there is enough contrast between front and background colors so that you can easily read the text. - If the library icon background color is light, use black color for the text. - If the library icon background color is dark, use white color for the text.
LabVIEW Class Wires
Avoid excessive wire patterns and colors Avoid creating excessive wire patterns and colors if you change the wire appearance of a LabVIEW class wire.
Details: - 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.
Use dark colors on the exterior of class wires Use dark colors on the exterior of class wires to provide contrast against the white background.
Use refnum color for wires if the private data contains only refnum types If the private data of a class contains only refnum types, use the standard refnum color for the class wire. Locate the color named "Refnum Wire" in the User Colors dialog box for the LabVIEW color picker.
Note: - This guideline takes precedence over other wire color guidelines.
Match class wire color to the icon banner color Make the color of the class wire match the color of the class icon banner.
Programming VI Block Diagrams
Avoid duplicating code Avoid duplicating code. Use subVIs or loops, as appropriate, to avoid code duplication.
Remove unused code (VI Analyzer) Remove unused code from block diagrams.
Avoid race conditions with appropriate synchronization Avoid race conditions by using appropriate synchronization techniques.
Details: - You can use queues, data value references, and semaphores to prevent race conditions. - You can also use functional global variables to prevent race conditions if the functional global variable protects a critical code section containing actions that modify data. - However, you cannot use a functional global variable to prevent race conditions if the functional global variable protects sections containing actions that only read and write data.
Handle unsupported values appropriately Handle all unsupported values appropriately.
Example: - If you create an API, consider returning an error for unsupported inputs.
Avoid creating platform-specific versions of VIs When designing multi-platform VIs, avoid creating per-platform versions of a VI. Instead, place platform-specific functionality in a Conditional Disable structure specific to a target.
Details: - Specifically, pay attention to Call Library Function Nodes as library file extensions may be different between platforms. If applicable, use an asterisk instead of the library file extension so the same configuration works on different platforms.
Avoid using absolute paths Avoid using absolute paths.
Details: - 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, consider ensuring that you include code to check whether the path exists and to create a path if the path does not exist.
Layout and Wiring
Use a left-to-right and top-to-bottom layout (VI Analyzer) Use a left-to-right and top-to-bottom layout.
Ensure data flows left to right (VI Analyzer) Wire so data flows from left to right, unless you use feedback nodes. If you need to use vertical wires in addition to horizontal wires, top-to-bottom flow is preferred over bottom-to-top flow when practical.
Details: - If your diagram contains a wire from right to left that is not associated with a feedback node, explain that decision using a wire label or an attached label.
Avoid using long wires unless necessary Avoid using long wires unless you have good reasons. If you must use long wires, use wire labels on those wires.
Wire neatly and efficiently (VI Analyzer) Wire neatly and efficiently. Keep the number of bends and wire crossings reasonable.
Rationale: - Poor wire organization can make the block diagram difficult to read and debug or make the VI appear to do things it does not do.
Arrange objects neatly on the block diagram (VI Analyzer) Neatly arrange objects on the block diagram.
Tip: - Use the Align Objects and Distribute Objects pull-down menus on the toolbar to arrange objects on the block diagram.
Avoid leaving front panel terminals unwired (VI Analyzer) When possible, avoid leaving front panel terminals unwired on the block diagram. Do not use a variable when you can use a terminal wire to transfer data.
Rationale: - LabVIEW is a data flow language, so wires are preferred from the maintainability perspective. Also, every local variable that reads the data makes a copy of the data.
Align control terminals to the left, indicator terminals to the right Align control terminals to the far left and indicator terminals to the far right of the block diagram. Align controls along their right edges and indicators along their left edges.
Exception: - This does not apply to indicator terminals used inside structures.
Lay objects neatly with reasonable spacing Lay objects neatly and with reasonable spacing to create a visually appealing block diagram. Do not wire under objects. Avoid unnecessary white space and overcrowding of the block diagram. Provide just enough white space for visual guidance.
Tip: - To increase space between tightly grouped objects, press <Ctrl> and drag in the direction you want to add space. (MacOS) Press <Option>. - To reduce space between scattered objects, press <Ctrl-Alt> and drag in the direction you want to remove space. (MacOS) Press <Option-Ctrl>.
Colors
Avoid coloring diagrams Avoid coloring diagrams. Color can distract users.
Use default colors for structures Use default colors for structures, such as Case or Event structures.