全部学习汇总: GitHub - GreyZhang/misra_c_hacking: MISRA C, I'm coming! Happy hacking!
13.1, 赋值操作不能够用以产生布尔量。
直白的翻译不是这样翻译,但是我觉得表达的含义应该是这样子。这里就需要有一个明确的认识了,判断条件true或者false应该使用布尔量或者布尔量表达式,但是为了在表达上更加具备可读性,我觉得可以强制做一个要求:判断条件必须是布尔量表达式,哪怕携程bool_func() == true这样的表达也是可以提高可读性并且避免问题的。另外一点,在进行布尔量表达式按断的时候不要使用例子中的第二种情况,也就是避免跟赋值一起使用。至于最后一个,原则上应该放弃这样讨巧的设计方式。
13.2, 除非操作数是布尔量,否则对0的测试应该是显式的。
针对这一条规则,我个人的想法应该是前面提到过的:无论什么时候,无论是否是布尔量,都得采用显式的0值测试,这样从表达上来说可读性以及防错性会更好一些。
13.3,整形表达式不能够用以做相等性的判断。
说起这一条规则,有成长学习经历的记忆。我个人的基础软件的能力是我工作很久以后才逐步建立的,在第一家公司的4年时间里对此并没有很深的积累。到了第二家公司,其实这方面练手的机会也不是很多。但是我有机会看了一些文件,在文件中发现了这么一条规则。其实,第一次看到的时候还不理解,后来补充了浮点数据的表达之后基本就理解了。其实,多个浮点数的数值在某些范围段中可能会出现二进制相同的情况,因此用以判断相等不合适。后来,接触Python学习,发现很多系统中浮点精度有一个eps的定义,也就是最小精度。对于浮点判断,很多时候我们可以借助于是否达到了最小精度的一定倍数来用以区分控制的效果。这都是一些陈年旧事的回忆了,回想过去的成长,曲折中摔跟头前进,内心五味杂陈。
13.4, for循环的主要作用其实还是一个遍历穷举功能,类似的处理还是尽量用整形做控制。这里做的要求是不要使用浮点的类型,主要是为了防止出现截断类以及前面反复提到的数据精度不同区间的异常影响。
13.5, for循环的3个表达式只应该与逻辑控制相关。
讨巧的做法,在for的表达式的非循环体中也可以做一些处理操作,这样的处理应该不允许。更为简单粗暴的做法其实可以把for定义为一个SICP中提到的map行为实现工具,这样把逻辑跟动作完全解耦,出现的问题就会更少也会更容易避免问题。另外,故意设计无限循环也是可以的。
13.7,不能够出现结果一直不变的布尔量表达式。
其实,出现这样的情况一般是考虑不充分。真是出现了,意味着软件其实是有优化空间的。当然,更多时候可能是出现了bug。但是在汽车电子领域,有一种情况可能会跟这一条规则很不一致。那就是通过标定实现的功能禁用或者激活,其实这样的违规情况就可能是一个很庞大的规模了。