嵌入式软件可靠性设计要注意的问题

4、数据、变量

变量的定义是为的避免各种混淆，同一程序内数据和数据的混淆、不同人读程序时对变量理解上出现的二义性、视觉效果上容易出现的错误(字母的"o"和数字的"0"，字母的"l"和数字的"1")。这里要遵循一个"要么相同，要么迥异"的基本规则，这条规则在很多的领域都有应用，用的最绝的是朱元璋，对待贪官，要么不理你，自觉点您贪差不多了就收手吧，您自己不收手的话，做的过了直接就杀，株连几族，所以在明朝，朱元璋是杀人最多的皇帝；在结构的防呆性设计上，接插件的选型也是如此，如果一个^^^白色和一个浅灰色的同类接插件，最好的选择是有很直观的视觉差异或结构的差异，或者干脆就是相同的，相同须基于一个前提，互换性要好。

用显意的符号来命名变量和语句标号。标识符的命名有明确含义，且是完整单词或易理解的缩写。短单词通过去掉"元音"形成缩写；长单词取头几个字母形成缩写；一些单词有公认的缩写。如：

Temp — tmp；

Flag — f.l.g；(*注：请去年中间的.号)

Statistic — stat；

Increment — inc；

Message — msg。

特殊约定或缩写，要有注释说明。在源文件开始处，对使用的缩写或约定注释说明。自己特有的命名风格，要自始至终保持一致。对于变量命名，禁止取单个字符(如i、j、k...)；含义+变量类型、数据类型等，i、j、k作局部循环变量是允许的，但容易混淆的字母慎用。如int Liv_Width，L代表局部变量(Local)(g全局变量Global)、i代表数据类型(Interger)、 v代表 变量(Variable)(c常量Const)、Width代表变量的含义，这种命名方式可防止局部变量与全局变量重名。

禁用易混淆的标识符(R1和Rl，DO和D0等)来表示不同的变量、文件名和语句标号。

除了编译开关/头文件等特殊应用，避免使用_EXAMPLE_TEST_之类以下划线开始和结尾的定义。

全局变量是战略性资源，它决定了模块和模块间的耦合度，需在项目上提升到一个足够高的高度，慎用全局变量，不得不用的时候，要单独为每一个全局变量编写独立的操作模块或函数，在修改全局变量的时候，要检查是否有别的函数在调用它并且需要此数值保持稳定。

对变量代表某个特定含义的时候，尽量不要仅仅用位来代表什么，比如用某变量的第零位代表某个状态(0000 0001，其中仅用1代表某个内容，这样01H、03H、05H… 会有很多个组合都能代表这个状态)；位容易受干扰被修改，信息出现错误的几率大很多。

也不要用00H、FFH等数据代表，就像我们面试一群人一样，第一个被面试人和最后一个被面试人容易被记住，00H和FFH亦然，系统默认状态是00和 FF的时候较多，他们容易被复位或置位成这类数值。推荐以四位的二进制码的某个中间值为状态变量，如1001。

变量数据在应用之前宜作数据类型和数值范围的判断；

数据在存储过程中也容易出现问题，EEPROM、RAM等都有过类似的案例。数据出错时避免不了的，解决的办法是学花旗银行等美国金融企业，之所以在 9.11后他们能很快恢复业务，基本没有数据方面的损失，原因何在？因为他们有异地容灾数据备份系统，知里面有两个关键词，异地、备份。我们的信息也同样，首先选择存在不同的介质中、或相同的介质但迥异的存放环境和位置下，双重备份的结局是两边不一致的时候，数据被怀疑并拒绝反映执行，但嵌入式软件很多时候是要靠数据来推动执行机构的，即使发现数据有问题也不允许行政不作为，这种情况下，作为我们也很难办，2个不同的数据，有明显问题的还好排除，都在有限范围内可如何判定哈？这种时候没办法只好三备份，少数服从多数是唯一的选择了。石头剪刀布的方式不好用，葛优的分歧终端机也不适用，就只好选择这种最原始最有效的办法了，唯一需要注意的是数据宜存放于三种不同的备份环境下，不然岂不成了你家哥俩儿，咋表决都占便宜啊。

以上仅就嵌入式软件可靠性的关注方面分了几大类，进行了基本的描述，实际应用中，需要关注的点还有很多很多，如果是准备自行制定设计规范的话，以上的思路应该也可以给与一些启迪了。

作者：武晔卿 来源：维库开发网