学习AutoSAR的时候，看到在MCAL中有API名为Mcu_PerformReset，撇开AutoSAR对架构本身的优缺点，单说Mcu_PerformReset这一个API。
直观想到的，是Mcu_PerformReset与Mcu_Reset在API命名上的区别。Mcu_PerformReset从API名称可以直译为Mcu执行Reset，很符合API设计的动词+名词原则，但是如果去询问100个软件工程师，我大概能确定有99个不能在这个API的名字中加上Perform，大家都会设计成Mcu_Reset，这是更符合习惯的API命名，所以我很想知道设计这个API的人心里的想法。
讲起API的命名，其实有一套约定俗成而一以贯之的原则。比如大小写混排加下划线，因为在不同的库中有不同的约定，到还不至于太过悖于习惯，但在命名的清晰易懂而有符合习惯上，委实会有常常令人摸不着头脑的地方。还是以Mcu_PerformReset为例，本身的命名固然看起来还不错，不过可以类比一下其他广泛使用的库，以及Linux本身的系统调用，这些库中的API命名，基本上可以代表当前广泛传播的函数命名约定和规范。
在cJSON库中，可以对拿到的json字符串进行解析，使用的API为cJSON_Parse。可以看到在命名规则上，与AutoSAR使用的大小写混排+下划线一致。不过如果依照Mcu_PerformReset，似乎命名为cJSON_PerformParse或者cJSON_DoParse会更加合理，然而如果这么命名，使用的人恐怕只会哭笑不得，因为实在是不能理解。pthread库中也有同样的情形，如果按照Mcu_PerformReset的原则，pthread的API应该是诸如pthread_perform_create，pthread_perform_join之流。kernel的系统调用实现更加不可目视，因为原本简洁的open，需要编程perform_open，而且对于kernel还不能变成do_open，因为内核有do_open的实现，同一系统中的多个do_open更加引起使用者的不适感。
那么在同一个Mcu模块中的明明，是不是能够遵循同样的原则呢？有图为证：
整个模块的API，只有Mcu_PerformReset显得鹤立鸡群，与其他API明明规则格格不入。德国人向来以严谨著称，何以如此？望有人解惑。
所以一份代码的风格，如果不能一以贯之，会引起参与者的极大不适感，且整篇代码在主要API的排布上，应该如流畅的散文一般行云流水，在辅以内部辅助函数，共同组成代码的架构。大体来说，不外函数命名，变量命名，空格规范，换行规范，预处理规范，错误规范几样。然而大部分人写出来的代码还是不忍卒读，甚至做不到格式一致，这固然是因为某些IDE对格式不敏感，但是比如换行，空格等，工程师应该形成手上的习惯，在键入for之后，自然会空格，然后在键入(，不用依赖于IDE的格式整理。IDE的格式整理，实际上培养了工程师的懒惰，以至于写完代码，经由IDE一整理，代码面目全非，他认识你，你不认识他，则开发效率，调试效率简直无从谈起。
