據說，趙國的首都邯鄲的人走路的姿態很好看，動作非常優雅、輕快。 燕國有一個少年聽到這個傳說，非常羨慕邯鄲人，就走了很遠的路去趙國，想學習邯鄲人走路的方法。剛開始，他整天站在街頭，仔細研究每個人走路的姿態，再慢慢模仿他們，可是都沒有成功。后來，他想可能是受到過去走路習慣的影響，所以，他決定要忘掉以前走路的方法。從那時候起，他更專心研究邯鄲人走路的姿勢，不過，再怎么努力他還是學不會，最后他只好放棄。可是，因為他把以前走路的方法忘得一干二凈，已經不知道該怎么走路，只好一路爬著回去。 http://www.hydcd.com/cy/gushi/0236hd.htm
【編碼規范的本質是什么？】
編碼規范是在一定范圍內強制推行的編碼習慣；這里的編碼習慣通常來自于對團隊有控制力的一個或者少數幾個人。
這里，你會很容易注意到三個關鍵字：“一定范圍”、“強制推行”和“編碼習慣”。抓住這三點，編碼規范的本質就像“任意不在同一直線上的三點確定一個平面”一樣——沒得跑了。
首先來說說這個“編碼習慣”，其實很好理解，它就是字面意思——一個人寫代碼時候的某種習慣，高情商叫風格，低情商叫“我就愛這么干，別問我為啥，我要么不知道，要么等我編個理由告訴你”。總之呢，編碼習慣帶有強烈的主觀性、基本上可以認為缺乏強有力的客觀依據，在穩定性和一致性方面其實就是水中花鏡中月——不能說完全沒有，只能說毫無可信度。
不信么？今天你看了一個大牛的代碼，覺得：
“哇！好牛逼”，
“大牛這么做一定有什么深意”
然后不自覺的就學著人家的編碼規范來了。過了幾天，你可能又碰到了另外的大牛，或者是什么明星開源項目……咋說呢……如果用男女關系來形容兄弟們的行為，那就是妥妥的渣男/渣女——沒得洗。
你跟我說說，哪兒來的穩定性和一致性？還不如先問問“你是誰的粉”比較靠譜。
很多時候，一個程序員自己的編碼習慣可能一輩子都沒有鯉魚躍龍門——成為編碼規范的機會；但如果有朝一日，你滿足了以下兩個條件，你的編碼習慣就是妥妥的編碼規范了：
擁有了一個完全由自己掌控的團隊或者項目；
擁有了執行決定的強制力；（比如KPI審核，扣工資之類）
【編碼規范的“原罪”】
無論是編碼規范還是編碼習慣，都只跟描述“你寫字丑不丑”、“漂不漂亮”的一個“主觀性非常強的”、甚至還帶有“藝術性玄學”的評價標準有關；
我們日常寫代碼其實可以類比為寫文章，這意味著：
你可以用非常漂亮的手寫體寫出狗屁不通的文章；
你也可以在趕時間的情況下，用一種只有自己看得懂的方式，快速而高效的寫出優秀的作品；
書法除了草書，往往暗示著——費時間；何況草書往往暗示著，除了那幾個評論家，普通人基本看不懂。
書法好壞和寫文章所需的遣詞造句的技法，以及文章整體的修辭、結構安排完全無關。
原罪1：膚淺引戰的導火索
……讀懂一段程序，實際上就是要通過死的代碼邏輯去反推模塊構作者的思維，這是一個逆向過程，這是一個人與人之間用代碼進行間接交流的過程，當邏輯本身較為復雜時，顯然比將自己的思維直接翻譯成程序（重新開發一個）更為困難。
傻孩子，公眾號：裸機思維真刀真槍模塊化(1)——一本糊涂賬
這里，我提到了一個關鍵的事實——閱讀他人代碼是非常耗時和困難的。這樣的事情無時無刻不在發生：當我們拿到一段代碼時，想通過了解它的內容來判斷好壞幾乎是不可能的——這不光意味著你要花費時間去閱讀它，可能你根本不想去閱讀，或者根本沒有這樣的時間去閱讀。此時，要想判斷一段代碼的好壞就只能通過非常表面的東西來進行了——是的，就是看你寫的字漂不漂亮。
如果明確知道這是“名人大家”的作品，或是出自某個大廠的作品，事情就變得非常簡單：只要學習歷來文人是如何在同行面前顯示自己學識淵博的方式——花式吹就行了。
如果要評價的對象是同輩的作品，或是某個來源不明的作品，大家就一下開始“審慎起來”，仿佛瞬間化身為嚴肅的藝術評論家——在嚴肅而充滿理性的批判聲中，自己“高超水平”和“恨鐵不成鋼的惋惜”躍然紙上。
原罪2：似是而非
這些“嚴謹大佬”們做出思考的背景是不同，而人們討論和傳播編碼規范的時候往往會丟棄這些背景信息而將其“泛化”——或者說無限制的擴大適用范圍；
很多作為某一編碼規范規則在背后的支撐邏輯，我們可以說它是“正確的”，但遺憾的是，它的正確“并不意味著其它做法是錯的”——事實上，有很多規則所服務的邏輯實際上存在很多“同樣正確、且平等的正確的競爭者”。
編碼規范的信徒們，往往視其它規范（甚至是某一個規范的變種）為異端，定要除之而后快，表現為與他人進行無意義的論戰、不說服他人加入自己的陣營就決不罷休，甚至上升到人身攻擊等等……
原罪3：遮羞布
【C語言編碼規范的“甜”和“咸”】
“純粹追求美觀”，顧名思義，代碼寫出來要眼睛看著舒服。需要特別強調的是，這里的看著舒服與“代碼的可讀性”完全是兩回事。
純粹追求美觀的杰出代表是Linux編碼規范——它所追求的是純粹小寫所帶來的那種和諧而統一的美；它基本不對函數、變量名、類型名做任何的區別（甚至是非常數的宏）；為了解決小寫單詞缺乏“節奏”的問題，而在單詞與單詞之間簡單的引入“_”完事。
這種美學就好比最優質的牛排，只需要輔以簡單的海鹽，進行簡單的烹飪就能發揮牛排最原始的美味；這就好比，新鮮的生蠔，只需要擠上幾瓣檸檬就可以釋放出最大的鮮甜……
正是由于Linux這種純粹追求視覺上的和諧而不“詭辯”自己有如何功能上的便利，受到眾多“返璞歸真”老鳥的狂熱追捧——我要的就是簡潔的美，其它都在我心間。
“純粹追求功能性”，顧名思義，就是以犧牲一定程度的“美感”而換取某種功能上的便利。實際上，完全犧牲美感的編碼規范幾乎沒有，但很多商用協議棧的編碼規范或多或少都有著明確的功能追求。
典型的是匈牙利變量命名法，它的特點是為每一個變量追加必要的類型信息，從而提高變量名的信息攜帶量——最終嘗試提高代碼的可讀性。在Linux玩家的眼里，匈牙利是真的丑；同時作為一個如入鮑魚之膚久而不聞其臭的匈牙利變量命名法玩家，我也只是“習慣了”這種用法，你要說我覺得它有多美，那也絕對是扯淡。有意思的是，匈牙利變量命名法往往會與駝峰命名法攪和在一起，這讓純粹的駝峰信徒頗為不爽——因為駝峰可以說是“美的”，但你非要粘上一些類型標簽——就好比在布丁的蜂蜜澆頭上發現了蒼蠅一樣惡心。
公平的說，匈牙利所附加的信息的確有助于提升代碼的可讀性。至于美不美，可以完全拋在腦后。
另外一類“追求功能性”的編碼規范就是各類DSP、視頻、音頻、數學相關的協議棧，它們純粹為了方便API的使用，嘗試在變量、函數以及類型名稱上附加大量的信息，以描述API的參數類型、函數所代表的的運算功能、以及其它相關專業方向才會理解的特性屬性等等——這樣的信息追加，造就了猶如喀斯特地貌一樣的奇觀——用是好用，美不美，就不好說了。這類協議棧的典型是鼎鼎大名的Dolby的音頻庫。
【編碼規范，怎么做才對？】
字寫的好看，是一種展示“認真態度”的方式；努力寫出漂亮的代碼無可厚非；
切記不可喧賓奪主，在本意是追求“如何寫出優秀作文”的時候，注意力過多的被“如何寫出漂亮字”的編碼規范所抓住，浪費不必要的時間；
不要把編碼規范上升成宗教信仰——哪怕你是無意識中這樣做的；
記住：優秀的程序員可以在任何編碼規范上隨意切換——這是你游刃有余的一種表現。
如果想討好一個人，贊揚他的書法；
如果一個群里的人讓你討厭，可以在退群之前，可以故意挑起關于編碼規范孰優孰劣的宗教戰爭——如果碰巧他們都是同一個宗教的信徒，則嘗試發起關于“怎樣才是正統”的討論。如果你喜歡一個群，就切記不要這么做。
在自己可控的范圍內——比如自己的開源項目里，隨意的使用自己的編碼規范。如果要跟他人合作，最好寫清楚自己的習慣，并且保持包容的心態——因為，請記住：
編碼規范的制定者往往會被所有人盯著，等著你的永遠是“你自己的規范你自己都沒遵守”，而不是“你的規范真好”的贊賞；
對任何你訂立的規則，你寫下來的只是你心目中的“默認情況”，而沒寫來的是大量你自己覺得合理的“特殊情況”——在你心中，除了“少數”特殊情況外，我們都應該按照“默認情況”來處理——可惜，這里的“少數”往往超出你的想像；
不要認為別人質疑你的編碼規范就是在罵你、質疑你或者找茬——哪怕大部分情況都是這樣；
同理，盡可能遵守它人的編碼規范，來展示自己對它人的尊重。看到“特例”不妨一笑了之。
干點正事吧！
【說在后面的話】
1.用它，只需幾個簡單指令就能開發俄羅斯方塊游戲！
2.芯片公司變成錢多多，制造企業真能買得起單？
3.為什么說i.MXRT不走傳統MCU套路？從外設寄存器訪問設計談起
4.該不該用RTOS？
5.移植mbedtls庫到MCU裸機的兩種方法
6.低耦合高內聚的MCU實用軟件框架~
免責聲明：本文系網絡轉載，版權歸原作者所有。如涉及作品版權問題，請與我們聯系，我們將根據您提供的版權證明材料確認版權并支付稿酬或者刪除內容。
