Jump to content

Style Guide: Difference between revisions

From LabVIEW Wiki
Category reorg
No edit summary
Line 1: Line 1:
Originally there existed a document entitled "LabVIEW with Style" -- A Guide to Better LabVIEW Applications for Experienced LabVIEW Users", authored by Gary W. Johnson and Meg F. Kay. Consider this document to be nominally obsolete. It is on the CD-ROM with the book "LV Graphical Programming" but was lost from the Info-LabVIEW ftp site with a great directory shuffle there some years ago (it was in a now-absent DOCS directory). The document does not appear to be on the NI ftp site either.
{{TOCright}}


There is a much better reference available now. If you buy the Professional version of LV6.0i, you get a printed manual called Development Guidelines. Even if you just get the non-pro version, install all the PDF manuals and you will find the same document as [http://www.ni.com/pdf/manuals/321393d.pdf LabVIEW Development Guidelines]. It's a wonderful little book, written by the VI Development team at NI with input from many... including that ancient style guide that Meg and I worked up. Highly recommended.
The following guidelines are provided as a reference for LabVIEW development. Individuals and organizations are encouraged to cater these to best serve their needs.  


Also on the NI website a search for STYLE GUIDE will locate the "Rules To Wire By" series by Rande Johnson. It's a great series, and may well meet your needs. Lots of wisdom there.
= Organization and Names of Directories, Projects, Libraries, Classes, and Files in General =


There are more works in progress on this subject, including one or more books (NOT by me!). And NI will keep revising the Development Guidelines book.
== 1.0.1 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.
 
== 1.1 Naming Files and Directories ==
 
=== 1.1.1 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.
 
=== 1.1.2 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.
 
=== 1.1.3 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.
 
=== 1.1.4 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
 
=== 1.1.5 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.
 
=== 1.1.6 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.
 
=== 1.1.7 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.
 
==== 1.1.7.1 Do not include the word "example" in any file or folder names. ====
 
==== 1.1.7.2 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.
 
==== 1.1.7.3 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.
 
==== 1.1.7.4 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”.
 
== 1.2 Project Organization ==
 
=== 1.2.1 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.
 
=== 1.2.2 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.
 
=== 1.2.3 Place all VIs in libraries, classes, or virtual folders ====
Avoid using auto-populating folders unless you have a good reason to use them.
 
=== 1.2.4 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.
 
== 1.3 Libraries ==
 
=== 1.3.1 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.
 
=== 1.3.2 Place APIs in a library ====
Place APIs in a library to improve organization.
 
=== 1.3.3 Mark non-API VIs as private ====
Mark any VIs in a library as private if they are not part of the API.
 
== 1.4 LabVIEW Classes ==
 
=== 1.4.1 Name all classes as nouns ====
''Example:''
- Name an example class Waveform Reader.lvclass rather than Reads Waveforms.lvclass.
 
=== 1.4.2 Name all member VIs of a LabVIEW class as verbs ====
''Example:''
- Name an example member VI Read Value.vi rather than Value.vi.
 
=== 1.4.3 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.''
 
=== 1.4.4 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."
 
=== 1.4.5 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."
 
=== 1.4.6 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.


One book that came out recently is "The LabVIEW Style Book" by Peter Blume.


== External links ==
== External links ==

Revision as of 17:05, 20 September 2024

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

Organization and Names of Directories, Projects, Libraries, Classes, and Files in General

1.0.1 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.

1.1 Naming Files and Directories

1.1.1 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.

1.1.2 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.

1.1.3 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.

1.1.4 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

1.1.5 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.

1.1.6 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.

1.1.7 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.

1.1.7.1 Do not include the word "example" in any file or folder names.

1.1.7.2 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.

1.1.7.3 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.

1.1.7.4 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”.

1.2 Project Organization

1.2.1 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.

1.2.2 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.

1.2.3 Place all VIs in libraries, classes, or virtual folders =

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

1.2.4 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.

1.3 Libraries

1.3.1 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.

1.3.2 Place APIs in a library =

Place APIs in a library to improve organization.

1.3.3 Mark non-API VIs as private =

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

1.4 LabVIEW Classes

1.4.1 Name all classes as nouns =

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

1.4.2 Name all member VIs of a LabVIEW class as verbs =

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

1.4.3 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.

1.4.4 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."

1.4.5 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."

1.4.6 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.


External links