LabVIEW软件编程规范.docx

LabVIEW软件编程规范.docx

《LabVIEW软件编程规范.docx》由会员分享，可在线阅读，更多相关《LabVIEW软件编程规范.docx（9页珍藏版）》请在冰豆网上搜索。

LabVIEW软件编程规范

LabVIEW软件编程规范

一、制定编程规范的意义

项目开发中,经常存在多人共同开发同一程序的情况。

风格不一致,导致的结果就是程序可读性差,难于维护。

为了避免这些问题,做为一个系统软件工程工作者,需要在工程项目开始之前有一套团队成员彼此遵守的开发规范。

制定本编程规范的目的就是为了提高软件开发效率及所开发的软件的可维护性,提高软件的质量。

本规范由程序组织结构、命名规则、注释规范、程序健壮性、可移植性、错误处理以及软件的模块化规范等部分组成。

二、编程规范

（1）程序组织结构

对于大型程序来说,如果规划不得当,会导致开发期间移动与重命名文件操作占用额外的时间。

所以一般采用目录结构（管理磁盘文件）-摘自《CRIO开发者指南》

LabVIEWVI就是根据其名称与路径进行关联,因此如果您移动或重命名子VI,关联就会遭到破坏,需要手动重新建立关联,适当管理磁盘上的文件会降低日后移动大量文件的风险,帮助开发人员很容易的找到文件,并决定在哪里保存新文件。

许多软件开发者已经规定好文件存储的位置,但就是除经典的方法与结构外,以下方法更适合大型程序的开发工作。

1）将所有项目文件存储到一个单一目录;

2）在其目录下创建包含文件逻辑群体的文件夹;

3）根据预定的标准对文件进行分组;

4）将程序划分为易处理的逻辑单元;

5）使用具有逻辑性与描述性的命名规则命名VI;

命名VI,VI库以及目录的时候,尽量避免使用不被所有文件系统所接受的字符,比如“/”,“\”,“:

”“~”。

文件名的命名要求表达出文件的内容,要求文件名的长度不得少于5个字母。

6）将顶层VI与其她源代码区分开来;

文件夹通常用来对文件进行分组、分类,因此可以针对不同的调用对子VI进行分组、分类。

文件分组的原则就是根据程序中文件的功能、类型以及分级层次来进行的。

实际上,磁盘管理真正体现了程序中文件与代码之间的关系。

避免在整个程序结构中使用相同的文件名。

因为在内存中一次只能有一个给定的名字。

如果内存中存在某个文件名的VI,而又试图去载入另外一个具有相同文件的VI,VI会提示您就是否替换已存在的VI。

这样会导致整个程序出现难以预料的问题。

如果打算备份VI文件的话,请务必确定把她们备份到正常搜索结构之外,以便LabVIEW不会错误的在内存中调用这些VI。

LabVIEWProject为开发人员提供了用于管理文件的工具。

随着程序不断壮大,开发人员需要对程序关联文件进行管理,如VI、控件资源、第三方函数库、数据文件以及硬件配置文件。

工程师可以利用LabVIEWProjectExplorer管理这些文件。

图１　LabVIEW项目上的源代码选项

开发者可以利用LabVIEWProject管理所有程序关联文件。

默认的项目文件夹为虚拟文件夹,但就是开发者可以将其与系统物理目录进行同步。

一旦开发者在LabVIEWProject中添加了一个目录,可以将其转变为“自动更新”,以最大限度地提高文件管理与组织灵活性。

自动填加文件夹会将磁盘文件管理与Project中的逻辑分组进行关联。

如果可能,最好使用自动更新文件夹来保护LabVIEW项目浏览器中的磁盘框架。

（2）命名规则

1）变量的命名规则

变量的命名规则要求采用“匈牙利法则”。

即开头字母用变量的类型,其余部分用变量的英文意思或其英文意思的缩写,尽量避免用中文的拼音,要求单词的第一个字母应大写。

、^1[7W"]0R"b  R  即:

变量名=变量类型+变量的英文意思（或缩写）

:

Q3A1c3n&t+x;E/M5z  对非通用的变量,在定义时加入注释说明。

变量类型见下表:

bool（BOOL） 用b开头    bIsParent

I8、I16、I32、I64用n开头  nStepCount

U8、U16、U32、U64用un开头  unSum

 float（FLOAT）  用f开头  fAvg

double（DOUBLE）  用d开头  dDeta

NHANDLE  用h开头  hHandle

path用p开头  pDDisk

enum用e开头  eMenu

wavedata用w开头  wAnalogData

cluster用clu开头  cluInformation

string用str开头  strName

Array用A开头  AName

全局变量用g_开头,如一个全局的长型变量定义为g_lFailCount,即:

变量名=g_+变量类型+变量的英文意思（或缩写）;

对常量命名,要求常量名用大写,常量名用英文表达其意思。

2P）J$|8f,a,n6^;Y7c+D!

e0C后缀定义:

1D一维数组

2D二维数组

iDi维数组

对未提及的变量类型的定义需在日后协商。

2）子VI的命名规则

1）子VI参数规范

①、参数名称的命名参照变量命名规范。

+Y;u%Z,a,~②、为了提高程序的运行效率,减少参数占用的堆栈,传递大结构的参数,一律采用指针或引用方式传递。

3）另外,用正确的反义词组命名具有互斥意义的变量或相反动作的函数等。

说明:

下面就是一些在软件中常用的反义词组。

add/removebegin/endcreate/destroy

insert/deletefirst/lastget/release

increment/decrementput/get

add/deletelock/unlockopen/close

min/maxold/newstart/stop

next/previoussource/targetshow/hide

send/receivesource/destination

cut/pasteup/down

（3）注释规范

1）子VI的注释

对于子VI,应该从“功能”,“参数”,“主要思路”、“调用方法”、“日期”六个方面用如下格式注释:

  ~'t0q2j9?

y）{5i

①、对于某些函数,其部分参数为传入值,而部分参数为传出值,所以对参数要详细说明该参数就是入口参数,还就是出口参数,对于某些意义不明确的参数还要做详细说明（例如:

以角度作为参数时,要说明该角度参数就是以弧度（PI）,还就是以度为单位）,对既就是入口又就是出口的变量应该在入口与出口处同时标明。

②、在注释中应该详细说明函数的主要实现思路、特别要注明自己的一些想法,如果有必要则应该写明对想法产生的来由。

对一些模仿的函数应该注释上函数的出处。

③、在注释中详细注明函数的适当调用方法。

在注释中要强调调用时的危险方面,可能出错的地方。

④#j%P$G  {3s:

w6q④④、对日期的注释要求记录从开始写函数到结束函数的测试之间的日期。

⑤、"h-E#d5}"\  f、Z2q）y⑤

对函数注释开始到函数命名之间应该有一组用来标识的特殊字符串。

如果算法比较复杂,或算法中的变量定义与位置有关,则要求对变量的定义进行图解。

对难以理解的算法能图解尽量图解。

2）变量的注释

对于变量的注释紧跟在变量的后面说明变量的作用。

原则上对于每个变量应该注释,但对于意义非常明显的变量,如:

i,j等循环变量可以不注释。

3）其她注释

在函数内我们不需要注释每一部分代码。

但必须在各功能模块的每一主要部分之前添加块注释,注释每一组代码,在循环、流程的各分支等,尽可能多加以注释。

其中的循环、条件、选择等位置必须注释。

对于前后顺序不能颠倒的情况,建议在注释中增加序号。

在其她顺序执行的程序中,必须加一个注释,注明这一段语句所组成的小模块的作用。

对于自己的一些比较独特的思想要求在注释中标明。

（4）程序健壮性

错误处理就是发现解决程序中出现的问题、战胜无法预料的事情与实现良好编程风格的根本。

1、错误处理基础

1）所有VI必须捕获并报告从错误端反馈回来的错误

2）通过错误端间错误簇的传递来捕获错误

3）捕获循环中每个迭代的错误

4）在循环中禁用错误的索引

5）在应用程序使用过程中,使用错误日志文件存储错误信息

6）在无人值守或远程控制的程序,禁用对话框报告错误。

7）避免使用内置错误报告的子ＶＩ

8）对Ｉ／Ｏ设备错误使用消极代码,对警告使用积极代码

编程中要求考虑函数的各种执行情况,尽可能处理所有的流程情况。

将函数分为两类:

一类为与屏幕的显示无关,（不与用户交换信息的函数）一类为与屏幕的显示相关。

（与用户交换信息的函数）对于与屏幕显示无关的函数,函数通过返回值来报告错误。

对于与屏幕显示有关的函数,函数要负责向用户发出警告,并进行错误处理。

严格的测试:

对每一段代码都要求进行严格的测试,特别对一些功能函数要对其各种临界点（比如零值、无穷大的值等）进行测试。

尽量做到每一段代码零错误。

（5）可移植性

-L、V9q（Q!

o4j、x0j:

v1、高质量的代码要求能够跨平台,所以我们的代码应该考虑到对不同的平台的支持,特别就是对windows98与windowsnt的支持。

2#?

#e#R5?

9I  z3U!

[22、对不同的硬件与软件的函数要做不同的处理。

（6）模块化

为了提高软件的重用性,减少重复开发的工作量。

同时也为了提高程序的可读性,方便程序的维护,必须加强软件的模块化工作。

模块化应该遵循以下几个基本规范:

1、函数应该作到精而小,函数的代码应该控制在一个适度的规模。

要求编写者更加详细的对函数注释,以及设计思想等。

2、某一功能,如果重复实现三遍以上,既应该考虑模块化,将其写成通用函数。

并向开发人员发布。

并要求将接口文档与实现的功能备案。

3、每一个开发人员要尽可能的利用其她人的现成的模块,减少重复开发。

4、对函数进行模块化时,要考虑函数的层次关系,特别就是在增加新的功能模块时,对原来的函数代码要进行认真的调整,做到相同功能的不同函数没有重复代码,此要求的目的在于便于代码维护。

模块化的一些注意事项:

①、设计好模块接口,包括:

函数接口与变量接口。

（7）程序备份

1、 要有备份记录

备份时注明备份日期与主要增加的功能

2、 定时备份

    根据程序量的多少,可以每天备份一次,也可以半天备份。

 3、 多种介质备份

   至少在硬盘上做2个备份,在软盘上做一个备份;在使用她人主机进行备份时,不可放于没有密码保护的ftp服务器上,可以发送到自己的email信箱中进行备份。

（8） 代码测试、维护

1.单元测试要求至少达到大代码覆盖。

2.单元测试开始要跟踪每一条代码,并观察数据流及变量的变化。

3.清理、整理或优化后的代码要经过审查及测试。

4.代码版本升级要经过严格测试。

5.使用工具软件对代码版本进行维护。

6.正式版本上软件的任何修改都应有详细的文档记录。

7.发现错误立即修改,并且要记录下来。

8.关键的代码在汇编级跟踪。

9.仔细设计并分析测试用例,使测试用例覆盖尽可能多的情况,以提高测试用例的效率。

10.尽可能模拟出程序的各种出错情况,对出错处理代码进行充分的测试。

11.仔细测试代码处理数据、变量的边界情况。

12.保留测试信息,以便分析、总结经验及进行更充分的测试。

13.不应通过“试”来解决问题,应寻找问题的根本原因。

14.对自动消失的错误进行分析,搞清楚错误就是如何消失的。

15.修改错误不仅要治表,更要治本。

16.测试时应设法使很少发生的