學(xué)習(xí)AutoSAR的時(shí)候，看到在MCAL中有API名為Mcu_PerformReset贮懈，撇開AutoSAR對(duì)架構(gòu)本身的優(yōu)缺點(diǎn)匀泊，單說(shuō)Mcu_PerformReset這一個(gè)API。
直觀想到的朵你，是Mcu_PerformReset與Mcu_Reset在API命名上的區(qū)別各聘。Mcu_PerformReset從API名稱可以直譯為Mcu執(zhí)行Reset，很符合API設(shè)計(jì)的動(dòng)詞+名詞原則抡医，但是如果去詢問(wèn)100個(gè)軟件工程師躲因，我大概能確定有99個(gè)不能在這個(gè)API的名字中加上Perform，大家都會(huì)設(shè)計(jì)成Mcu_Reset忌傻，這是更符合習(xí)慣的API命名大脉，所以我很想知道設(shè)計(jì)這個(gè)API的人心里的想法。
講起API的命名水孩，其實(shí)有一套約定俗成而一以貫之的原則镰矿。比如大小寫混排加下劃線，因?yàn)樵诓煌膸?kù)中有不同的約定俘种，到還不至于太過(guò)悖于習(xí)慣秤标，但在命名的清晰易懂而有符合習(xí)慣上绝淡，委實(shí)會(huì)有常常令人摸不著頭腦的地方。還是以Mcu_PerformReset為例苍姜，本身的命名固然看起來(lái)還不錯(cuò)牢酵，不過(guò)可以類比一下其他廣泛使用的庫(kù)，以及Linux本身的系統(tǒng)調(diào)用衙猪，這些庫(kù)中的API命名馍乙，基本上可以代表當(dāng)前廣泛傳播的函數(shù)命名約定和規(guī)范。
在cJSON庫(kù)中垫释，可以對(duì)拿到的json字符串進(jìn)行解析丝格，使用的API為cJSON_Parse】闷可以看到在命名規(guī)則上铁追，與AutoSAR使用的大小寫混排+下劃線一致。不過(guò)如果依照Mcu_PerformReset茫船，似乎命名為cJSON_PerformParse或者cJSON_DoParse會(huì)更加合理，然而如果這么命名扭屁，使用的人恐怕只會(huì)哭笑不得算谈，因?yàn)閷?shí)在是不能理解。pthread庫(kù)中也有同樣的情形料滥，如果按照Mcu_PerformReset的原則然眼，pthread的API應(yīng)該是諸如pthread_perform_create，pthread_perform_join之流葵腹。kernel的系統(tǒng)調(diào)用實(shí)現(xiàn)更加不可目視高每，因?yàn)樵竞?jiǎn)潔的open，需要編程perform_open践宴，而且對(duì)于kernel還不能變成do_open鲸匿，因?yàn)閮?nèi)核有do_open的實(shí)現(xiàn)，同一系統(tǒng)中的多個(gè)do_open更加引起使用者的不適感阻肩。
那么在同一個(gè)Mcu模塊中的明明带欢，是不是能夠遵循同樣的原則呢？有圖為證：
整個(gè)模塊的API烤惊，只有Mcu_PerformReset顯得鶴立雞群乔煞，與其他API明明規(guī)則格格不入。德國(guó)人向來(lái)以嚴(yán)謹(jǐn)著稱柒室，何以如此渡贾？望有人解惑。
所以一份代碼的風(fēng)格雄右，如果不能一以貫之空骚，會(huì)引起參與者的極大不適感纺讲，且整篇代碼在主要API的排布上，應(yīng)該如流暢的散文一般行云流水府怯，在輔以內(nèi)部輔助函數(shù)刻诊，共同組成代碼的架構(gòu)。大體來(lái)說(shuō)牺丙，不外函數(shù)命名则涯，變量命名，空格規(guī)范冲簿，換行規(guī)范粟判，預(yù)處理規(guī)范，錯(cuò)誤規(guī)范幾樣峦剔。然而大部分人寫出來(lái)的代碼還是不忍卒讀档礁，甚至做不到格式一致，這固然是因?yàn)槟承㊣DE對(duì)格式不敏感吝沫，但是比如換行呻澜，空格等，工程師應(yīng)該形成手上的習(xí)慣惨险，在鍵入for之后羹幸，自然會(huì)空格，然后在鍵入(辫愉，不用依賴于IDE的格式整理栅受。IDE的格式整理，實(shí)際上培養(yǎng)了工程師的懶惰恭朗，以至于寫完代碼屏镊，經(jīng)由IDE一整理，代碼面目全非痰腮，他認(rèn)識(shí)你而芥，你不認(rèn)識(shí)他，則開發(fā)效率膀值，調(diào)試效率簡(jiǎn)直無(wú)從談起蔚出。
