编码规则(可维性).doc

维护性 2006/11/10 V1.00 大多嵌入式软件开发中，都会在制作完成的软件上进行维护作业。 　 维护的原因各种各样，例如： 发布的软件中发现Bug，需要修改。 对应产品的市场要求，以既存软件为基础，追加新的功能。 　等等。 　 像这样，在制作好的软件上加工，要尽量避免错误，有效的进行。 　系统界管这叫维护性。 　在此，整理了维护、提高嵌入式软件源代码维护性的一些惯用方法。 维护性１???意识到其他人也会看你的代码。 维护性２???使用不会改错得方法。 维护性３???把程序尽量简单化。 维护性４???统一编码方法。 维护性５???使用便于测试的编码方法。 维护性６???Uniden（株）Know-how集。 维护性１ 意识到其他人也会看你的代码。 在制作源代码时考虑到，它会被制作者以外的技术者再利用或维护。因此，源代码要使用容易理解的表现方式。 「维护性1 」有以下１２个惯用做法。 维护性１.１　不保留不使用的代码。 维护性１.２　不使用麻烦，杂乱的写法。 维护性１.３　不使用特殊的写法。 维护性１.４　演算的优先顺序明确易懂。 维护性１.５　不省略取得函数地址的演算、比较演算。 维护性１.６　一个领域用于一个目的。 维护性１.７　不重复使用名字。 维护性１.８　不使用容易理解错的语言规格。 维护性１.９　在特殊的方法中写明意图。 维护性１.10　不掩埋Magic Number。 维护性１.11　明示领域属性。 维护性１.12　不编译的语句也要正确记述。 维护性1.1　不遗留不使用的代码。 M1.1.1　不声明（定义）没有使用的函数、变量、参数、标签。 参考规则　无 相关规则　M1.9.1 M4.7.2 M1.1.2　不应该把代码的一部分“Comment out”。 参考规则　MISRA-C 2.4 相关规则　M1.2.1 M4.7.2 ＜正确例＞ 　 #if 0 /* 因为～、无効化 */ a++; #endif ＜不正确例＞ ??????? /* a++; */ ??????? } 如果需要把代码部分无効化，建议不要用Comment out，而是用#if 0圈住。 或者确定一个无効化代码的明确规则也行。 但是，留下无効代码会导致代码不好读，还是应该避免的。 note 在调试时，会Comment out一部分代码，但是调试结束后不要忘了解除Comment ，否则可能会发生Bug。如果限制了Comment out代码，就可以在早期发现这些Bug。 维护性1.2　不使用麻烦，杂乱的写法。 M1.2.1　用于相同目的的相同类型的自动变量，可以用１个声明语句进行多次声明，但是不可以混合初始化的变量和不初始化的变量。 参考规则　无 相关规则　M1.6.1 ＜正确例＞ 　 int j, k; int l = 0; int *p; int q; ＜不正确例＞ int j, k, l = 0; /* 混有初始化的内容 */ int *p, q; /* 混有不同类型的变量 */ 如果声明了int *p;，那么类型就是int *、如果声明了int *p, q;，q的类型不是int *、而是被解释为int。 　note 　 　　写常量时，如果不使用接尾语的话，整数常量为int型、浮动小数点常量为double型。但是，整常量中如果有int不能表现的值，那么这个值将会变成能表现它的类型。因此，0x8000在int为16bit时为unsigned int，但在 int为 32bit时变成signed int。如果想把它作为unsigned使用的话，把”U”写为接尾语。另外，在浮动小数点的float型和double型演算速度不同的Target System中，进行float型的变量和浮动小数点的演算时，如果浮动小数点常量中没有”F”，这个演算就会变成”double”型的演算，这一点需要注意。要在浮动小数点常量上多下些功夫，使其一看就能知道是浮动小数点常量，比如在小数点左右最少要写一个数字等等。 　　　 特别是在演算精度、演算速度很重要的程序中，必须要充分理解实际是使用的那种类型的演算。（不要Cut＆Try。） 整数常量的类型 接尾语u/U: unsigned int, unsigned long 接尾语l/L: long, unsigned long 接尾语u/Uとl/Lの両方: unsigned long 浮动少数点常量的类型 接尾语f/F: float 接尾语