LabVIEW软件编程规范Word下载.docx
《LabVIEW软件编程规范Word下载.docx》由会员分享,可在线阅读,更多相关《LabVIEW软件编程规范Word下载.docx(9页珍藏版)》请在冰豆网上搜索。
文件名的命名要求表达出文件的内容,要求文件名的长度不得少于5个字母。
6)将顶层VI与其她源代码区分开来;
文件夹通常用来对文件进行分组、分类,因此可以针对不同的调用对子VI进行分组、分类。
文件分组的原则就是根据程序中文件的功能、类型以及分级层次来进行的。
实际上,磁盘管理真正体现了程序中文件与代码之间的关系。
避免在整个程序结构中使用相同的文件名。
因为在内存中一次只能有一个给定的名字。
如果内存中存在某个文件名的VI,而又试图去载入另外一个具有相同文件的VI,VI会提示您就是否替换已存在的VI。
这样会导致整个程序出现难以预料的问题。
如果打算备份VI文件的话,请务必确定把她们备份到正常搜索结构之外,以便LabVIEW不会错误的在内存中调用这些VI。
LabVIEWProject为开发人员提供了用于管理文件的工具。
随着程序不断壮大,开发人员需要对程序关联文件进行管理,如VI、控件资源、第三方函数库、数据文件以及硬件配置文件。
工程师可以利用LabVIEWProjectExplorer管理这些文件。
图1 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)避免使用内置错误报告的子VI
8)对I/O设备错误使用消极代码,对警告使用积极代码
编程中要求考虑函数的各种执行情况,尽可能处理所有的流程情况。
将函数分为两类:
一类为与屏幕的显示无关,(不与用户交换信息的函数)一类为与屏幕的显示相关。
(与用户交换信息的函数)对于与屏幕显示无关的函数,函数通过返回值来报告错误。
对于与屏幕显示有关的函数,函数要负责向用户发出警告,并进行错误处理。
严格的测试:
对每一段代码都要求进行严格的测试,特别对一些功能函数要对其各种临界点(比如零值、无穷大的值等)进行测试。
尽量做到每一段代码零错误。
(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.测试时应设法使很少发生的