LabVIEW Style Guide

柔光的暖阳◎ 2021-12-20 22:45 400阅读 0赞

**LabVIEW Style Guide**  
  
Describes recommended practices for good programming technique and style. Remember that these are only recommendations, not  
strict rules.  
  
Inconsistent style causes problems when multiple developers work on the same project. The resultingVIs are difficult tomaintain and can confuse users. To avoid these problems, establish a set of style guidelines for VI development. You can establish an initial set of guidelines at the beginning of the project and add more guidelines as the project progresses. The most important thing is not the specific style you use, but the consistent use of that style.  
  
This article includes style checklists to help you maintain quality as you develop VIs. To save time, review the list before and during development.  
To create a successful VI, consider who needs to use the VI and for what reasons. Remember the following:  
  
• Users need a clear front panel.  
• Developers need an easy to read block diagram.  
• Users and developers need thorough documentation.  
  
Use this article and the style checklists as a starting point for creating your own style guide. Customize this article to fit your development preferences and to meet the specifications of your project.  
  
**Organizing VIs in Directories**  
  
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.  
Create a directory for all the VIs for one application and give it a meaningful name, as shown in Figure 6-1. Save the main VIs in this directory and the subVIs in a subdirectory. If the subVIs have subVIs, continue the directory hierarchy downward.  
  
When you create the directory, organize the VIs and subVIs modularly. Figure 6-1 shows a folder, MyApp, containing a VI-based application. The main VI, MyApp.vi, is in this folder along with the folders containing all the subVIs. Notice that these folders are organized according to the functionality of the subVIs.  
  
![o\_folder.gif][o_folder.gif]  
Figure 6-1. Directory Hierarchy  
  
When naming VIs, VI libraries, and directories, avoid using characters that are not accepted by all file systems, such as slash (/), backslash (\\), colon (:), and tilde (~). Most operating systems accept long descriptive names for files, up to 31 characters on Mac OS 9.x or earlier and 255 characters on other platforms.  
  
Avoid creating files with the same name anywhere within the hierarchy. Only one VI of a given name can be in memory at a time. If you have a VI with a specific name in memory and you attempt to load another VI that references a subVI of the same name, the VI links to the VI in memory. 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.  
  
Refer to Creating VIs and SubVIs, of the LabVIEW User Manual for more information about saving VIs individually and in VI libraries. Refer to the LabVIEW Help for more information about adding a new directory to the VI Search Path.  
  
**Front Panel Style**  
  
Front panels must be well-organized and easy to use because users see the front panel first when working with a VI. When designing a front panel, keep in mind two types of users, the end user and the developer. End users work with user interface VIs, which have front panels that only the end user sees, and developers work with subVIs, which have front panels that only developers see.  
  
**Fonts and Text Characteristics**  
  
Do not use all the fonts and styles available. Limit your 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. Refer to the LabVIEW Help for more information about setting the default font, using custom fonts, and changing the font style.  
  
The actual font used for the three standard fonts 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. Use carriage returns to make multiline text instead of resizing the text frame.  
  
To prevent labels from overlapping objects because of font changes on multiple platforms, allow extra space between controls. For example, if a label is to the left of an object, justify the label to the left and leave some space to the right 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.  
  
**Colors**   
  
With many options for colors, developers commonly encounter the problem of using too many colors. 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, multiplot graphs and charts can lose meaning when displayed in black and white. Use line for plot styles in addition to color.  
• Consider coloring 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. • Be consistent in use of color.  
• Always check the VI for consistency on other platforms.  
  
**Graphics and Custom Controls**  
  
You can enhance the functionality of the front panel with imported graphics. You can import bitmaps, Macintosh PICTs,Windows Enhanced Metafiles, and text objects to use as front panel backgrounds, items in pict rings, and parts of custom controls and indicators, as shown in Figure 6-2.  
  
![o\_6-2.gif][o_6-2.gif]  
Figure 6-2. Example of Imported Graphics Used in a Pict Ring  
  
Check how the imported pictures 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 UNIX.  
  
Refer to the Porting and Localizing LabVIEW VIs Application Note for more information about importing graphics on different platforms. 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. That way, the object does not have to be redrawn each time the indicator is updated.  
  
**Tip** If youmust use a large background picture with controls on top of it, divide the picture into several smaller objects and import them separately. Large graphics usually take longer  
to draw than small ones.   
  
**Layout**  
  
Consider the arrangement of controls on front panels. Keep front panels simple to avoid confusing the user. For example, you can usemenus to help reduce clutter. For top-level VIs that users see, place the most important controls in the most prominent positions. Use the Align Objects and the Distribute Objects pull-down menus to create a uniform layout.  
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 are much slower to draw and might flash.  
Use decorations, such as a Raised Box or Horizontal Smooth Box, to visually group objects with related functions, as shown in the following figure. Use clusters to group related data. Do not use clusters for aesthetic purposes only.  
  
![o\_6-3.gif][o_6-3.gif]  
Figure 6-3. Using Decorations to Visually Group Objects Together  
  
For subVI front panels, place the controls and indicators of the subVI so that they correspond to the connector pane pattern. Refer to the Connector Panes section of this chapter for more information about connector pane style.  
To describe the purpose of the VI or object and to give users instructions for using the VI or object, create descriptions and tip strips for the VI or object.  
Refer to the LabVIEW Help and Chapter 15, Documenting and Printing VIs, of the the LabVIEW User Manual for more information about creating VI and object descriptions and tips.  
  
**Sizing and Positioning**  
  
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. Refer to the LabVIEW Help for more information about customizing the window appearance.  
  
**Labels**  
  
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. The Required, Recommended, Optional setting for connector pane terminals affects the appearance of the inputs and outputs in the Context Help window.  
  
The name of a control or indicator needs to 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 labeling a ring or slide 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 programatically.  
  
For Boolean controls, use the name to give an indication of which state corresponds to which function and to indicate the default state. 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 can help clarify the meaning of each position on a switch, as shown in Figure 6-4.  
  
![o\_6-4.gif][o_6-4.gif]  
Figure 6-4. Free Labels on a Boolean Control  
  
**Paths Versus Strings**  
  
When specifying the location of a file or folder, 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. Make sure you set the browse options appropriately on the Browse button of file path controls. For example, if the user needs to select a folder, make sure the SelectionMode option in the Browse Options dialog box is set to existing dir.  
  
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.  
  
**Enumerated Type Controls Versus Ring Controls**  
  
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.  
Ring controls are useful for front panels the user interacts with, where you want to programmatically change the string labels. You may 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.  
  
**Default Values and Ranges**  
  
Expect the user to supply invalid values to every control. You can check for invalid values on the block diagram or right-click the control and select Data Range to set the control item to coerce values into the desired range: Minimum, Maximum, and Increment.  
  
Set controls with reasonable default values. A VI should not fail when run with default values. Remember to show the default in parentheses in the control label for subVI front panels. 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 high-level file VIs such as the Write Characters to 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.  
  
Other difficult situations must be dealt with 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. If one or more of the controls are not readily available, you can request the present settings from the instrument to ensure you do not try to set an invalid combination.  
  
**Property Nodes**  
  
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 using Property Nodes to enhance ease of use:  
  
• 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 window 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.  
  
**Key Navigation**  
  
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 your VIs even if the use of a mouse is available. Keyboard shortcuts add convenience to a VI.  
  
Pay attention to the key navigation options for buttons on the front panel. Set the tabbing order for the buttons to read left to right and top to bottom. Set the <Enter> key to be 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 tomove 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 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.  
  
Refer to Chapter 4, Building the Front Panel, of the LabVIEW User Manual for more information about controlling button behavior with key navigation. Refer to the LabVIEW Help for more information about setting the tabbing order of front panel objects.  
  
**Dialog Boxes**  
  
Dialog boxes are an effective way to gather settings and configuration information from the user. Use dialog 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 modern 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. Refer to Chapter 4, Building the Front Panel, of the LabVIEW User Manual for more information about creating dialog boxes.  
  
**Block Diagram Style**  
  
The block diagram is the primary way for others to understand how a VI works, therefore it is often worth the effort to follow a few simple steps to make block diagrams more organized and easier to read.  
  
Style is as important on the block diagram of the VI as on the front panel. Users may not see the block diagram, but other developers do. A well-planned, consistent block diagram is easier to understand and modify.  
  
**Wiring Techniques**  
  
You can 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.  
  
The following are other good wiring tips for keeping the block diagram clean:  
  
• Avoid placing any wires under block diagram objects such as subVIs or structures because LabVIEW can hide some segments of the resulting wire. Draw your wires so that you can clearly see if a wire correctly connects to a terminal.  
• 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.  
• Delete any extraneous wires.  
• Avoid the use of local variables when you can use a wire to transfer data. Every local variable that reads the data makes a copy of the data.  
• Do not wire through structures if the data in the wire is not used in the structure.  
• Space parallel wires evenly in straight lines and around corners.  
  
**Memory and Speed Optimization**  
  
There are many things you can do to optimize usage and execution time of a LabVIEWVI. Optimization is important when a program has large arrays or critical timing problems. Refer to the LabVIEW Performance and Memory Management Application Note for more information about optimizing your VIs.  
  
Even though optimization can be a very involved topic, you can take the following basic actions to optimize an application:  
• If speed is not necessary to aWhile Loop, add aWait function to avoid slowing down other tasks. 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. The slowing of tasks outside of the loop results in the computer seeming slow even though it is running a simple loop. Adding a slight delay between iterations with the Wait (ms) function can dramatically 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. The delay does not require any data dependencies, as shown in Figure 6-5.  
  
![o\_6-5.gif][o_6-5.gif]  
Figure 6-5. While Loop with 50 Millisecond Delay  
  
Use the Wait Until Next ms Multiple function to time the loop iterations more precisely. Refer to the LabVIEW Help for more information about the difference between the Wait function and the  
Wait Until Next ms Multiple function.  
  
To avoid this problem completely, use an Event structure. Event structures do not require processor time while waiting for a user  
interface event.  
  
• 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. A more efficient method of building an array is to use auto-indexing or to pre-size the array and use the Replace Array Element function to place values in it. Similar issues exist when dealing with strings because, in memory, LabVIEW handles strings as arrays of characters.  
  
• Use global and local variables as sparingly as possible. You can use both global and local variables to write VIs very efficiently. However, if you misuse or abuse global and local variables, particularly with data types, the memory usage of the VI increases and the performance is affected.  
  
Additionally, you can encounter race conditions when reading from and writing to global variables in the same application. These race conditions are difficult to debug since there is no data dependency between different instances of the same 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. Refer to the Using LabVIEW to Create Multithreaded VIs for Maximum Performance and Reliability Application Note for more information on using functional global variables.  
  
• Choosing the proper array data type for the data to be handled is important in controlling the memory usage of the application. For example, if you have an extended-precision floating-point array of 100,000 values, but the actual values stored in the array are single-precision floating-point values, there is an inefficient use of memory. Using an array of single-precision floating-point values to match the data type stored in the array reduces the memory usage. The following table shows the difference in memory usage.  
  
• Avoiding coercion dots also can reduce unnecessary memory usage and speed. Coercion dots indicate that LabVIEW converted the value wired to the node to a different representation, which means that LabVIEW made a copy of the data. The effects of coercion dots become more dramatic when you have large arrays of data of inconsistent data types.  
  
• 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. To optimize the performance of the VI, display only the necessary information on the front panel and send data to indicators only if the data is different from what the indicator already displays.

<table style="width:320px;border-collapse:collapse;"> 
 <tbody> 
  <tr> 
   <td>Array Data Type</td> 
   <td>Memory Used</td> 
  </tr> 
  <tr> 
   <td>Array of 100,000</td> 
   <td>EXT values 1 MB</td> 
  </tr> 
  <tr> 
   <td>Array of 100,000</td> 
   <td>SGL values 400 KB</td> 
  </tr> 
  <tr> 
   <td>Memory Saved</td> 
   <td>600 KB</td> 
  </tr> 
 </tbody> 
</table>

**Sizing and Positioning**  
  
The size of the block diagram window can affect how readable your LabVIEW code is to others. Make the block diagramwindowno larger than the screen size. In addition to the size of the block diagram window, it is also important to ensure that the LabVIEW code displayed is not too large.  
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 only has to scroll in one direction, horizontal or vertical, to view the rest of the code.  
  
**Left-to-Right Layouts**  
  
LabVIEW uses a left-to-right layout so block diagrams need to follow this convention. While the positions of program elements do not determine execution order, avoid wiring from right to left. Only wires and structures determine execution order.  
  
**Block Diagram Comments**  
  
Developers whomaintain and modify VIs need good documentation on the block diagram.Without it,modifying the code ismore time-consuming and error-prone. The following are some suggestions for commenting the block diagram. Refer to the LabVIEW Help for more information about creating free labels.  
  
• Use comments on the block diagrams to explain what the code is doing. LabVIEW code is not self-documenting even though it is graphical. The free label located on the Functions palette has a colored background which works well for block diagram comments.  
  
• 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 free labels on 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.  
  
• Use labels on structures to specify the main functionality of that structure.  
  
• Use labels on constants to specify the nature of the constant.  
  
• Use labels on Call Library FunctionNodes to specify what function the node is calling and the path to the library being called.  
  
• Use comments 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.  
  
**Call Library Function Nodes and Code Interface Nodes**  
  
VIs that contain Call Library Function Nodes and Code Interface Nodes (CINs) are platform specific. VIs that call shared libraries using a Call Library Function Node are platform dependent and only function 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.  
  
If you write any VIs that contain CINs, you need a different version of the VI for each platform because CINs contain code compiled with platform-specific compilers. When you move VIs that contain CINs to other platforms, you must recompile the code for the new platform and reload it into the CIN. For this reason, only use CINs if they provide functionality not available with shared libraries.  
  
If a VI contains a Call Library Function Node or a CIN and you want to use that VI on multiple platforms, consider creating different versions of the VI that contain the Call Library Function Node and the CIN for each platform.  
  
**Type Definitions**  
  
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, LabVIEWautomatically propagates changes to the control or the data structure throughout all the VIs and subVIs.  
  
Refer to the LabVIEW Custom Controls, Indicators, and Type Definitions Application Note for more information about using type definitions.  
  
**Sequence Structures**  
  
Use sequence structures sparingly since they hide code. Try to 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. To help control data flow, you can use error clusters.  
  
If you must use a sequence structure, consider using a Flat Sequence structure so you do not hide any code. If you use a Stacked Sequence structure in the VI, save the VI with the most important frame showing. Refer to Chapter 8, Loops and Structures, of the LabVIEW User Manual for more information about using sequence structures.  
  
**Icon and Connector Pane Style**   
  
Using good style techniques when creating the icons and connector panes for VIs can greatly benefit users of those VIs.  
  
**Icons**   
  
The icon represents the VI on a palette and a block diagram.When subVIs have well-designed icons, developers can have a better understanding of the subVI without the need for excessive documentation.  
  
Use the following suggestions when creating icons:  
  
• Create ameaningful icon for every VI. The LabVIEW libraries are full of well-designed icons that try to show the functionality of the underlying program; use them as prototypes where applicable.  
When you do not have a picture, text is acceptable. If you localize the application, make sure you also localize the text on the icon.  
  
Tip A good size and font choice for text icons is 8 point Small Fonts in all caps.  
  
• Do not use colloquialisms when making an icon. Colloquialisms are difficult to translate. Users whose native language is not English may not understand what the icon does from a picture that does not translate well. For example, do not represent a datalogging VI with a picture of a tree branch or a lumberjack.  
  
• Create a unified icon style for related VIs. This helps users visually understand what subVI calls are associated with the top-level VI.  
  
• Always create a black and white icon for printing purposes. Not every user has access to a color printer.  
  
• Always create standard size (32 × 32 pixels) icons. VIs with smaller icons can be awkward to select and wire. Smaller icons also tend to look strange when wired.  
  
• Make sure the subVI icon is visible on the block diagram. Right-click the subVI and select Visible Items»Terminals. Make sure there is no checkmark next to the Terminals options. The subVI icon is more helpful than the connector pane on the block diagram.  
  
**Example of Intuitive Icons**   
  
The Report Generation VIs are examples of icons designed with good style techniques.  
  
![o\_6-6.gif][o_6-6.gif]  
Figure 6-6. Report Generation VIs  
  
The Report Generation VIs use images of a disk, a printer, a pencil, and a trashcan to represent what the VIs do. The image of a piece of paper with text on it represents a report and is a common element in the icons. This consistency unifies the icon designs. Notice that none of the icons are language dependent, thus they are suitable for speakers of any language.  
  
Refer to Chapter 7, Creating VIs and SubVIs, of the LabVIEW User Manual for more information about creating icons.  
  
**Connector Panes**  
  
A connector pane is the set of terminals that correspond to the controls and indicators of a VI. Refer to Chapter 7, Creating VIs and SubVIs, of the LabVIEW User Manual for more information about setting up connector panes.  
  
Use the following suggestions when creating connector panes:  
  
• Always select a connector pane pattern with extra terminals. Unforeseen additions to the VI may require more terminals. Changing patterns requires relinking to the subVI in all calling VIs and may result in wiring incompatibilities.  
  
![o\_good%20connector.gif][o_good_20connector.gif]  
A good connector pane pattern is the 4 × 2 × 2 × 4 pattern, shown at left.  
  
• Wire inputs on the left and outputs on the right to follow the standard left-to-right data flow.  
  
![o\_good%20connetor2.gif][o_good_20connetor2.gif]  
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, either 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, shown at left.  
  
• Choose the same connector pane pattern for related VIs. Wire related inputs and outputs on opposite terminals so that references, taskIDs, error clusters, and other common terminals line up correctly.  
  
• Try to choose only connector pane patterns with 16 or fewer terminals. While patterns with more terminals might seem useful, they are very difficult to wire. If you need to pass more data, use clusters.  
  
![o\_8%20connector.gif][o_8_20connector.gif]  
• The connector pane should have a minimum of eight terminals, using the 4 × 4 pattern, shown at left. This pattern ensures that all VIs, even VIs with few inputs, line up correctly and have straight wires connecting them.  
  
• 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, align the input and output connections to simplify the wiring patterns.  
  
• Use the Required, Recommended, Optional setting for every terminal to prevent users from forgetting to wire subVI connections.  
  
Use required for inputs that must be wired for the subVI to run properly. Use optional for inputs that have default values that are appropriate for the subVI most of the time.  
  
• Include error in and error out clusters on 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.  
  
• Strive for similar arrangements between panel and connector pane layouts.  
  
Refer to the LabVIEW Help for more information about creating connector panes.  
  
**Style Checklist**  
  
Use the following checklists to help you maintain consistent style and quality. You can copy these checklists to use on all LabVIEW projects.  
  
You also can add, remove, or modify any of the following guidelines to customize these checklists to fit the specifications of your project.  
  
**VI Checklist**  
  
❑ Organize VIs in a hierarchical directory with easily accessible top-level VIs and subVIs in subdirectories.  
❑ Avoid putting too many VIs in one library because large LLBs take longer to save.  
❑ Use Tools»Edit VI Library to mark top-level VIs within an LLB.  
❑ Create a .mnu file, if the VIs will be used as subVIs. Be sure to arrange the palettes, name the menus, and hide dependent subVIs.  
❑ Give VIs meaningful names without special characters, such as backslash (\\), slash (/), colon (:), and tilde (~).  
❑ Use standard extensions so the operating system can distinguish files (.vi, .ctl).  
❑ Capitalize first letters of VI names.  
  
❑ Distinguish example VIs, top-level VIs, subVIs, controls, and global variables by saving them in subdirectories or separate libraries in the same directory, or by giving them descriptive names such as X Main.vi, X Example.vi, X Global.vi, and X TypeDef.ctl.  
❑ Write a VI description, proofread it, and check the Context Help window.  
❑ Include your name and/or company and the date in the VI Description on the Documentation page of the VI Properties dialog box.  
❑ Create a meaningful black and white icon in addition to a color icon.  
❑ Choose the 4 × 2 × 2 × 4 connector pane pattern to leave extra terminals for later development. Use a consistent layout across related VIs.  
❑ Avoid using connector panes with more than 16 terminals.  
❑ Use Required, Recommended, and Optional settings on the connector pane.  
❑ Set print options to display the output in the most useful format.  
❑ Make test VIs that check error conditions, invalid values, and Cancel buttons.  
❑ Save test VIs in a separate directory so you can reuse them.  
❑ Load and test VIs on multiple platforms, making sure labels fit and window size and position are correct.  
❑ Avoid using VIs that are platform specific if the VIs need to run on multiple platforms.  
❑ Consider creating different versions of VIs that contain platform specific VIs and functions.  
  
**Front Panel Checklist**  
  
❑ Give controls meaningful names. Use consistent capitalization.  
❑ Make the background of control and indicator labels transparent.  
❑ Check for consistent placement of control names.  
❑ Use standard, consistent fonts—application, system, and dialog—throughout all front panels.  
❑ Use Size to Text for all text for portability, and add carriage returns if necessary.  
❑ Use path controls instead of string controls to specify the location of files or directories.  
❑ Put default values in parentheses on captions for controls in subVI front panels.  
❑ Include unit information in names. If applicable, for example, use Time Limit (10 Seconds).  
❑ Write descriptions for controls and indicators, including array, cluster, and refnum elements. Remember that you might need to change the description if you copy the control.  
❑ Create tip strips for front panel items so users have an easy way to understand the functionality of controls on user interface VIs.  
❑ Arrange controls logically. For user interface VIs, put the most important controls in the most prominent positions. For subVIs, put inputs on the left and outputs on the right and follow connector pane terminals.  
❑ Arrange controls attractively, using the Align Objects and the Distribute Objects pull-down menus.  
❑ Do not overlap controls.  
❑ Use color logically and sparingly, if at all.  
❑ Provide a Stop button if necessary. Do not use the Abort button to stop a VI. Hide the Abort button.  
❑ Use ring controls and enumerated controls where appropriate. If you are using a Boolean control for two options, consider using an enumerated control instead to allow for future expansion of options.  
❑ Use custom controls or typedefs for common controls, especially for rings and enums.  
❑ Label custom controls with the same name as the file. For example, Alarm Boolean.ctl has the default name Alarm Boolean.  
❑ Make sure that all the controls on the front panel are of the same style. For example, do not use both classic and 3D controls on the front panel.  
  
**Block Diagram Checklist**  
  
❑ Avoid creating extremely large block diagrams. Limit the scrolling necessary to see the entire block diagram to one direction.  
❑ Label controls, important functions, constants, Property Nodes, local variables, global variables, and structures.  
❑ Add comments. Use object labels instead of free labels where applicable and scrollable string constants for long comments.  
❑ Place labels below objects when possible and right-justify text if label is placed to the left of an object.  
❑ Use standard, consistent font conventions throughout.  
❑ Use Size to Text for all text and add carriage returns if necessary.  
❑ Flow data from left to right. Wires enter from the left and exit to the right.  
❑ Align and distribute functions, terminals, and constants.  
❑ Label long wires with small free labels with white backgrounds.  
❑ Avoid placing block diagram objects, such as subVIs or structures, on top of wires.  
❑ Do not wire behind objects.  
❑ Use path constants instead of string constants to specify the location of files or directories.  
❑ Make good use of reusable, testable subVIs.  
❑ Use error in and error out clusters in all subVIs.  
❑ Make sure the program can deal with error conditions and invalid values.  
❑ Show name of source code or include source code for any CINs.  
❑ Consider using a Flat Sequence structure if you have a sequence structure in the VI.  
❑ Save the VI with the most important frame of multiframed structures (Case, Stacked Sequence, and Event structures) showing.  
❑ Review the VI for efficiency, data copying, and accuracy, especially parts without data dependency.  
❑ Make sure the subVI icon, rather than the connector pane, is visible on the block diagram.  
❑ 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. ❑ If you open references to a LabVIEW object, such as an application, control, or VI, close the references by using the Close LV Object Reference function. Otherwise, the reference stays in memory even though the VI no longer uses it.  
❑ 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.  
❑ Place any control on the connector pane of a subVI on the left side of the block diagram.  
❑ When designing a subVI, make sure control and indicator terminals on the connector pane are not insides structures on the block diagram.

转载于:https://www.cnblogs.com/Qia\_sky/articles/113423.html

[o_folder.gif]: /images/20211220/c98a4fd7e19d449d9009688eaca4e807.png
[o_6-2.gif]: /images/20211220/eaac48dc7851425487382b3fa2fa5f9f.png
[o_6-3.gif]: /images/20211220/b6ec6c67fe4d4b5bac33812faae71d58.png
[o_6-4.gif]: /images/20211220/d5ea342c691346b8aed86e84d59e1e60.png
[o_6-5.gif]: /images/20211220/4fd1007955f349a593972ab6fab7f723.png
[o_6-6.gif]: /images/20211220/d3e90566ab8f491e891f7edcb0c2adf0.png
[o_good_20connector.gif]: /images/20211220/798393ce5a0f4106ab0b0385903b3521.png
[o_good_20connetor2.gif]: /images/20211220/d95b77a042634e44a09d062594f4734c.png
[o_8_20connector.gif]: /images/20211220/6ccf5041b34c49e08fe8caa08fb81ee0.png