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