代码编写规范和技巧

在编写程序时，除了需要它满足运行正确这个最基本的要求外，还会要求它具有良好的可读性和可维护性。具有良好可读性和可维护性的程序代码都有一些共同之处。实际上，本书的各个章节中，都针对具体问题，各有侧重地介绍了如何编写美观和健壮的程序代码。下面再具体介绍一些编写程序代码时比较通用的规范和技巧。

简洁的程序框图

一个程序，要想让他人容易看明白，首先就应该简洁。如果一个程序框图上只有四五个子 VI 或函数、一两个结构，那么，基本上一眼就可以看明白程序的内容了。如果一个程序框图上有四五十个子 VI、函数，各种循环和条件结构层层相套，数据线纵横交错，恐怕看不了几眼就会头晕眼花，更别说轻易弄懂它的意思了。

理想状态下，一个 VI 的程序框图上就应该只包括四五个子 VI 或函数、一两个结构。并且，这个 VI 的程序框图应该符合常用的程序结构或模式。看一眼就可知道，这个 VI 的程序框图采用的是状态机结构或循环事件结构等。一般程序阅读者对这些常用结构模式是有一定了解的。在阅读程序时，若能够套用已有的知识，就可以大大加快理解速度。

一个功能很复杂的程序，不可能只用四五个函数就完成。那么，应该考虑尽可能把大的功能拆分成多个子 V：主 VI 由四五个子 VI 组成；而每个子 VI 也只包含四五个函数或更底层的子 VI；依次层层类推。

LabVIEW 和文本语言不同，除了那些需要被重复使用的代码应该被做成子函数外，对于那些过于庞大或复杂的代码，即便它不会被其它地方调用，也应当被拆分为子 VI，以提高程序可读性。在一个项目中，如果每个子 VI 的程序量都很少，那肯定非常容易被理解。但是，它也会带来一些不利之处。

第一，子 VI 数量过多。程序员最担心的可能就是子 VI 数量过多是否会影响程序运行效率。使用子 VI 确实会占用一些额外的运算资源，但这些额外的开销非常微小，绝大多数情况下都可以忽略不计。如果对程序效率要求极高，即使是子 VI 这样不易察觉的额外开销也需要去掉的话，那么可以在程序开发阶段，依然正常地编写子 VI，以不影响程序可读性。但是在程序发布时，利用 VI Scripting 提供的功能，另外再编写一段程序，把所有子 VI 都合并到主 VI 中去。让最终发布的程序只有主 VI，没有子 VI，以提高运行效率。

第二，程序的层次比较多。程序的调用关系过多，可能会不利于阅读整个程序的全部代码。但实际上在团队工作中，每个程序员仅仅负责一个项目的一小部分。他主要关心整个项目的结构，以及自己负责那一部分的细节。而对于项目其它部分的细节则关心不多。所以，项目中模块和层次划分得越详细，子 VI 越多，反而越有利于程序员理解程序大致流程，以及有利于维护自己负责的那一小部分。

前面提到的是理想状况。实际编程时，因为创建子 VI 也需要花费一些额外的编程时间，程序员往往更注重当前程序的编写速度，而不是优化程序风格。为了加快编程速度，程序员甚至愿意牺牲程序的可维护性。毕竟，将来维护这段程序的可能不是他自己，而目前程序的编写的速度比风格更容易受到领导好评。

所以，在实际制定编程规范时，可以采用折中方案。每个子 VI 可以更复杂一些，包含更多的节点。但这个程序框图复杂程度的上限就是不超过一个屏幕的显示范围。目前，主流显示器的面积都是比较大的，VI 的程序框图的面积最大也不应当超过显示频幕的面积，这样，程序框图上的所有代码都可以在不拖动滚动条的前提下，在显示区域内显示出来。

很多初学者，为了尽可能多地在程序框图上添加内容，会把程序框图设置为全屏显示。实际上，在编写大型程序的时候，经常需要同时查看 VI 的前面板，以及子 VI 的程序框图。把一个 VI 的程序框图最大化，不便于同时查看其它窗口的内容。所以，VI 的程序框图窗口最好不超过屏幕的 2/3。

布局和连线

内容相同的两个程序框图也会有可读性的差别，这主要取决于程序框图上节点的布局和连线的排布。一般来说，排布整齐，连线方向一致的程序，肯定比杂乱无章的程序框图更容易阅读和理解。

排布程序框图时，主要应该注意以下几点：

• 程序框图上所有的连线的方向都应该是从左向右，数据在数据线上的流动总是从左向右。从左到右，是阅读时最自然的习惯。
• 程序框图上有一个主要数据线贯穿程序左右。这个数据应该是比较重要的数据，比如文件的引用、某个仪器设备、某个类等等。有了这个主线，其他人就可以顺着它来阅读代码。
• 数据线应当尽量减少弯曲和交叉。由于数据都是从左向右流动，理论上它们应当是平行的。

下图是一个示例程序框图的布线，这样的程序是非常容易阅读的：

把程序框图上一个个的节点、连线排列整齐，是要花费一些时间的，比较麻烦。好在 LabVIEW 提供了自动排布程序框图的功能，堪称是懒汉福星。点击 VI 程序框图窗口工具栏上的“整理程序框图”按钮，就可以自动整理程序框图。它可以在不改变程序的逻辑关系的前提下，调整程序框图上节点和连线的位置，使它们更整齐易读。比如下面这个杂乱的程序框图：

在点击“整理程序框图”按钮后，变成了下面工整的程序框图：

但是，这个工具毕竟比不上人脑更智慧，经过整理的程序框图虽然比原来整洁很多，但还是无法与人工调整出来的程序框图一样美观。

注释

为了帮助他人更快地理解程序逻辑或一些比较特殊的实现方法，为代码添加文字说明是必不可少的。在 LabVIEW 中添加文字说明，首先应该做到以下几点：

• 使用有意义的控件或常量名称；
• 显示节点的标签，并使用有意义的文字；
• 为子 VI 创建有意义的图标。

程序框图上的各种节点和结构也和控件一样，是有标签的，只是默认状态下不显示。对于 LabVIEW 的各种结构，推荐使用子程序框图标签（Subdiagram Label）添加注释。在结构的右键菜单中选择 “可见项目 -> 子程序框图标签”：

结构的上方会变成一处添加文字的区域，把当前框图的注释写在这里即可。这一区域的背景颜色，字体颜色都是可以调整的。

使用标签添加注释的好处：一是比较容易统一整个项目的注释风格，二是注释会始终保持与节点和结构的相对位置，不会因为代码布局的调整而错乱。

如果仅使用节点和结构的标签任然不够，比如作为教学、展示等用途的程序可能需要格外详细的解释说明，那么还可以在程序框图上添加一些文本标签，在文本标签中添加详细的注释文字。

注释应当尽量靠近被注释的节点或连线。如果注释文字过长，为了不影响程序正常的代码，也许只能把注释写在离被注释节点或数据较远的地方。为了使注释更加醒目和直观，可以使用以下两种风格的注释方式。

第一种，使用箭头表明注释针对的节点或数据，如下图所示：

LabVIEW 的文本标签自带箭头，不需要额外再使用箭头装饰。把鼠标放在文本标签上，标签右下角会出现一个小图标，拉动它，就会出现一个箭头（如下图所示）。拖动这个箭头到需要注释的节点或结构，箭头就会锚定在上面。这样，将来无论是移动了节点，还是移动了注释标签，都不用担心它们失去关联。

第二种，使用标号把注释文字和被注释的节点或数据关联起来，如图下图所示：

标号最好也使用文本标签自带的箭头用被注释节点锚定起来。

使用文本标签做注释有一个局限：它的布局可能会被“整理程序框图”工具破坏。因为它可能导致程序中注释的位置出现错误。在 LabVIEW 的程序中，文本标签和程序上的节点，连线等没有逻辑关系。“整理程序框图”工具并不知道它们内容的关联性，在整理程序框图的过程中，节点的位置发生变化，注释摆放的位置也会发生变化。带有箭头锚定的文本标签会摆在相对较合理的位置，没有锚定的文本标签可能会被放到完全不相关的位置上。

使用自定义数据类型

“簇”类型的数据是一种很常见的数据。编写比较大型的程序时，可能多个子 VI 的参数中都有同一种簇类型的数据。比如说，一个用于保存某一实验数据的程序，其中多个 VI 用到了同一个“实验信息”数据类型。“实验信息”是一个簇，它由两个元素组成，分别是“实验名称”和“实验时间”。

在程序的编写过程中，可能会发现这个簇数据的类型需要改动。原来的两个元素不够用，程序还需要添加“实验编号”这一信息：

由于程序中多个子 VI 都用到了这一数据类型，一旦它发生变动，就需要把所有用到这个簇的 VI 都进行相应修改。这样的修改不但繁琐，更糟糕的是可能会遗漏某些数据没有改动，造成程序潜在的错误。

解决这一问题的方法是为类似的数据创建一个自定义类型。自定义数据类型同自定义控件一样，保存在.ctl 文件中。它的创建方法也与自定义控件相同。区别在于需要把它的控件类型设置为“自定义类型”或“严格自定义类型”。在程序中，如果用到了这个.ctl 文件，就把它叫做这个自定义控件或自定义类型的实例。

自定义控件与它的实例之间没有任何关联。如果使用自定义控件制作并保存了一个漂亮的按钮控件。需要用到它时，通过拖拽或打开这个.ctl 文件就可以在 VI 前面板上添加一个此类用户自定义控件的实例。这个实例一旦生成，就和原用户自定义控件无任何关联了。无论是你修改这个实例，还是修改原用户自定义控件，都不会对另一方产生任何影响。

自定义类型与严格自定义类型在 VI 上生成实例的方法与自定义控件相同。不同之处在于：自定义类型以及严格自定义类型与它们的实例之间是相关联的。比如，创建一个数值类型的自定义类型，它的所有实例也都是数值型的。如果在自定义类型文件中把这个控件的数据类型改为字符串，那么它已有的所有实例都将自动变成字符串类型。

对于严格自定义类型，它和它的实例之间，不但数据类型是相关联的，控件的属性也是相关联的。这些属性包括控件的颜色、大小以及枚举或下拉列表类型控件的项目等，也是相关联的。

比如，在使用自定义类型时，自定义类型上的控件是一个文本下拉列表控件，它的数据类型是 U16 数值型。控件中包括两个下拉选项：“条目一”和“条目二”。如果在自定义类型中，为它多添加一项 "条目三"。这时候，因为数据类型还是 U16 不变，它所有的实例不会跟随它更新，实例中的枚举型控件还是只有两项。但如果使用了严格自定义类型，则它所有的实例会自动更新，也都变为三项。

LabVIEW 中有些数据类型以及它们的属性经常会在编程过程中进行调整，比如簇、枚举、下拉列表、组合框、数组、波形图等。为了便于随时修改它们，在编程时，凡是遇到这样的数据类型，就该为它们制定一个严格自定义类型定义。当需要所有实例控件的外观都保持一致时，也应该使用严格自定义类型。

连线板

为了保持程序框图上连线的整齐，所有的子 VI 都应当尽可能采用相同模式的连线板。

比如，可以规定程序中所有 VI 的连线板都必须采用 4224 模式：（按照每一列接线端的数量命名此模式）。所有 VI 中的输入参数，用连线板左侧的六个接线端表示；输出参数用右侧的接线端表示。子 VI 在程序框图默认是显示子 VI 的图标，但也可以把它的连线板显示出来：在子 VI 图标上点击鼠标右键，选择“显示项 -> 接线端”即可。

下图所示的程序中，所有子 VI 都统一采用了 4224 模式的连线板。这样就可以保证每个 VI 参数接线端所在的位置是固定的。两个子 VI 中，同一排上的参数接线端，它们的相对高度肯定是相同的。这样，它们之间连接数据线，就可以保证数据线是一条直线，没有弯折。

若程序框图上每个子 VI 采用不同模式的连线板，则他们的接线端很难都保持在同一高度，连线难免出现转折处。如下图所示：

4224 模式的连线板总共有 12 个接线端。如果 VI 的参数（输入输出控件）太多，超过 12 个，就没法使用这一模式了。但实际上，VI 的参数不宜太多，一般应该控制在 8 个以下。如果超过这一数字，不但这个 VI 使用起来比较麻烦，调用它的代码的可读性也成问题。一个子 VI 中联出十几根数据线，程序阅读者分辨起来就非常费劲了。

如果 VI 需要输入或输出较多的数据，可以把其中类似或相关的数据合并起来，用一个数组或簇来表示它们，以减少参数的数量。或者采用其它方式在 VI 间传递数据，比如使用全局变量。

参数对应的连线板接线端位置，应与参数控件在 VI 前面板上的位置相对应。这样做是为了方便程序阅读者直观地了解接线端与控件的对应关系。比如下图所示的 VI，它的连线板上接线端的布局与前面板上控件的布局完全一致。所以读者一眼就可以认出，连线板上第一列第二排接线端表示的参数是“AC Filter Bandwidth”。

图标

图标是 VI 非常重要的一部分，精心设计的图标可以大大提高程序的可读性。设计 VI 图标时应该注意以下几点。

千万不要使用默认的图标。使用默认图标会导致一个程序框图上所有的子 VI 看上去都是同一个模样，根本分不清楚哪个图标是哪个 VI。

尽量使用图形而不是文字。人对图形的接受和处理速度远高于文字，所以以图形标识的图标不但更美观，也可以被人更快速地阅读。有时候，编程者绞尽脑汁也想不出一个合适的图标，干脆在图标里写上几个字。这样就失去了图标的意义。因为子 VI 的名字，或注释等都以文字表示，没必要再重复一遍。如果是临时、内部使用的 VI 还可以只在图标上写文字，正式发布给用户的 VI 一定要定义有意义的图案。

同一个功能模块，或同一个库中的 VI 的图标应当有统一风格，让人一看，就知道它们之间是相关的。这种统一风格可以体现在图标的配色方案一致，或者都有同样的组成元素，比如相同的标签，或图形部分。下图中的两组 VI，第一组是某一仪器驱动程序的 VI，它们都用共同的一个红色“AG34401”标签；第二组是 LabVIEW 处理配置文件的 VI，们都拥有一个用来表示文件的相同图案。

LabVIEW 中的图标最大尺寸是 32×32 个像素点，这也是默认的大小。一般来说，在程序中都采用默认的大小就可以了。图标也可以做成其它尺寸和不规则图形。在某些特殊的情况下，可以采用不规则的图标美化 LabVIEW 程序框图。下面列举两个这方面的例子。

制作不规则图形的子 VI 图标

大多数子 VI 的图标都是一个正方块。但有时候，为了程序代码美观、易读，需要把子 VI 做成不规则图形显示在调用它的父 VI 代码上。LabVIEW 中很多自带的函数，比如说加减乘除运算函数等，就没有采用规则的 32×32 的正方形图标。在应用程序中也可以把子 VI 做成非正方形方块的，例如下图中的 My Function.vi，就把它的图标做成了三角形。

把子 VI 的图标改为非规则图形，有一些事项需要注意。首先，要考虑选取一个合适的连线板模式。LabVIEW 默认的模式是 4224 模式。但这种模式通常不适用于不规则的图标。比如说上图的 My Function.vi，它需要一个纵向位于中央的输出接线端，而 4224 模式最右侧的 4 个接线端对称分布，没有一个位于中间。

在 VI 前面板的图标上点击鼠标右键，选择“显示连线板”，之后再鼠标右击，选择“模式”，就可以挑选一个合适的模式了。对于 My Function.vi，可以使用 52225 这个模式。如下图所示：

接下来，就是核心工作 —— 编辑图标了。其中最重要的两点：

• 一是不要给图标加上边框
• 二是，如果使用的旧的图标编辑器，图标编辑器上的三个颜色的图标必须保持一致

下图是 LabVIEW 的旧式图标编辑器，它的中央有三个小方块，分别显示黑白色、16 色、256 色下的 VI 图标。用鼠标点击一下某个小方块，左边的编辑区就开始对这个颜色的图标进行编辑。

目前的显示器的颜色数都高于 256 色，所以在程序框图中看到的始终都是 256 色那个图标；只有在古老的显示器上，颜色数少于 256，比如只有 16 色，那么在程序代码上看到的子 VI 显示的就是 16 色的那个图标。不过现在恐怕找不到 16 色的显示器了，所以 16 色这个图标一般情况下就是空白。黑白色的显示器虽然更罕见，但是这里的黑白图标还有另一个用处，就是确定图标中图形的轮廓。所以一定要有一个形状和 256 色图标相符合的黑白图标才能做出不规则图形图标来。一般在编辑黑白图标时，按一下“复制于 256 色”的按钮，把 256 色的图标复制过来就可以了。

编辑不规则形状的图标时，最好选中“显示接线端”，把连线板模式在图标编辑区显示出来。这样可以方便地查看图标的图形是否与连线板接线端相匹配。比如说，要在连线板右侧中央的接线端接一个输出数据，图形至少要覆盖到这个接线端才行。

新的图标编辑器已经彻底淘汰了黑白色和 16 色图标。直接把图标设置为不规则图形就可以了：

隐藏程序框图上的大个簇常量

在编写某些程序的时候可能会遇到如下图所示的情形：即用到了一个极为复杂的数据类型常量。这个常量由于体积巨大，使得在程序框图无论怎样布局都让人看起来不太舒服。如何才能把这个程序改造得美观一些呢？

要解决这个问题，只有设法把这个常量在主程序框图上隐藏起来。通常可以用以下两种方法。

第一种方法：把这个常量变换成控件，再把控件隐藏起来。这种方法比较简单，但是也有弊病。首先，容易引起误解：控件一般表示有值传入，他人阅读程序时就可能搞不清楚这个值是从哪里传来的了；其次，若要修改簇常量中某一个元素的值，操作起来比较麻烦。

第二种方法是把它隐藏到更深层的子 VI 中去。具体操作方法如下：

如下图所示，先给这个复杂数据类型建立一个严格自定义类型。

然后再建立一个新的 VI，把要隐藏的这个个头巨大的常量摆放在这个 VI 中，并且为它创建一个同类型的显示控件，把它的值传出来。VI 的连线板采用 4224 模式的，第四排第三列的接线端用于传出 VI 中唯一的数据，如图下图所示：

这个 VI 的图标要做得小巧漂亮，如下图所示：

把这个新造出来的常量数据 VI 拖到程序框图上，把它的输出连接到刚才连接常量的地方，再把位置摆放好。这样的程序看起来是不是漂亮多了：

VI 分析器

实际上，编写程序时需要注意的规范还有很多。若要程序员把所有的规范都牢记下来并在编程时处处按规范行事，也是比较困难的。在编程时难免有疏忽，那就需要一条找出这些疏忽的途径。LabVIEW 中的“VI 分析器”工具就可以用来查找程序代码中的错误或风格有问题的地方。

“VI 分析器”是一个向导型界面的程序，点击菜单项“工具 ->VI 分析器 -> 分析 VI”将启动“VI 分析器”工具。按照界面的提示，一步一步下去即可对 VI 进行分析。

“VI 分析器”工具会打开每一个被检测的 VI，按照预定的规范进行检查。比如检查程序中是否有拼写错误，控件排列是否准确等。这些检查或测试条目以插件的形式存在，用户还可以编写自定义的检查插件。所有测试插件均在 [LabVIEW]\project\_VI Analyzer\ 文件夹下。

如果电脑上仅安装了 LabVIEW，可能一个插件都没有。对 VI 中常见的错误和毛病的检查插件在“VI Analyzer Toolkit”中。安装了这个 Toolkit 后，“VI 分析器”工具就具备检查 VI 常见问题的功能了。

下面三张插图是“VI 分析器”向导界面中的几个重要步骤的截图。

首先要在“VI 分析器”中选择被测试的 VI（上图）。可以选择一个项目中的所有 VI，也可以选择一个路径，检测路径中所有的 VI。作为示例，此处选取 [LabVIEW]\examples\xml 路径下的所有 VI 进行分析。

之后，需要选择对 VI 进行哪些测试（上图）。有些测试项目可能并不那么重要，比如不需要关心是否在循环内有数组或字符串的运算。只要不勾选这些项目，就不会检测它们了。

“VI 分析器”检测结束后，会把所有发现的问题列出来（上图）。这之中，有很多问题可能是误报或并不重要，那不必理会。错误可能性高、并且严重的问题会以红色叹号标注出来；次要问题以蓝色叹号标注。对于这些问题要格外注意。结果窗口的“说明”栏会指出问题的详细内容。

如果这段说明还是不很直观，可以双击该条目，LabVIEW 会自动打开有问题的 VI，并将问题之处高亮显示出来（上图）。