1225_MISRA_C规范学习_预处理命令规则要求

全部学习汇总： GitHub - GreyZhang/misra_c_hacking: MISRA C, I'm coming! Happy hacking!

19.1， 这一条应该难以全部实现，比如在AUTOSAR的软件中进行存储分区是很常见的。而存储分区其实是在反复包含memmap的一个头文件。这样的处理机制就很难保证这一条规则的符合，好在这只是一个建议而不是强制。

19.2， 这一条似乎几乎是不可能出现的一个规则要求，应该少有人会在代码文件命名的时候选择使用这样的符号来给自己增加麻烦。

19.3， 这条规则好像在给我更多选择的样子，其实最后一个用法在看到之前我甚至是直接不会考虑到的。

19.4， 宏定义使用有使用上的诸多限制，主要是在展开内容的限制上。而我个人在代码设计的时候，基本上都是满足这样的要求的。甚至说，我使用的范围会比这个范围更小一些。最多是定义几个符号或者是常量，如此而已。这样，可以在很大程度上简化设计的思维模式。

19.5， 代码块中不能够用#defined以及#undefined，虽然这个在语法本身上没有问题。但是这样的使用可能会给人带来误导，让人认为这个有效的范围只是在这个代码块的范围内。其实，不管是在什么地方使用，这个有效范围都是全局的。

19.6， #undef尽量不要用。

19.7， 能够使用函数的时候，尽量不要用宏定义。

19.8， 类函数的宏没有参数传入的时候，不要进行调用。

19.9 类函数的宏中不要再增加预处理的指令，不然这样的处理很令人费解。

19.10， 类函数的宏每一个参数都要放到相应的括号中去。

19.11， 预处理中的所有符号都应是定义过的，判断是否存在或者定义涉及到的命令除外。

19.12， #或者##操作符在一个宏定义中至多出现一次。这个我个人是直接没有用过的，但是呢，我在一个多核的工程里面看到了基础的代码中用这种方式扩展出来三个不同内核的下标信息。想来，我自己设计软件的时候可能继续不会使用。

19.13， 跟我考虑的一样，其实在编码的建议中也是建议上面的这个不要用。

19.14， #defined只允许使用两种标准的形式。

19.15， 这个或许是我在软件设计中用的比较多的一个，也就是很多人说的防止重复包含的include-sandwitch。

19.16， 所有的预处理操作都要有明确的用途。

19.17， 条件分支类的预处理表达，全都放在同一个文件之中。

到此为止，整个MISRA C 2004关于预处理命令的一些要求就已经全都梳理晚了。