來源 | 碼磚雜役

責編 | Carol

封圖 |?CSDN 付費下載自視覺中國

我們經常談論架構，討論設計，卻甚少關注實現和代碼本身，架構和設計固然重要，但要說代碼本身不重要，我不同意，Robert C.Martin大叔也不同意，Martin認為“源碼即設計”。

在討論具體的實施細則之前，我們不妨討論一下什么是好代碼？Robert?C.Martin認為：衡量代碼質量的唯一標準是：WTF/min，也就是review代碼的時候每分鐘說“握草”的次數。這個定義雖有辱斯文，但粗野中不失奔放，調皮中又蘊含哲理。

好的代碼如同文筆優美的散文，行云流水，賞心悅目，閱讀的時候，如沐春風，帶給人愉悅與啟迪。

好的代碼猶如構思精巧的小說，它或許不夠平鋪直述，卻足夠引人入勝，讀到最后，你會豁然開朗：原來是這樣的啊，那一刻，你會覺得過程中的曲折和探索都是值得的。

好的代碼，透過一個個函數，你仿佛可以窺視到作者有趣的靈魂；透過一行行代碼，你仿佛在與一個充滿智慧的朋友聊天，她總是條理清晰，邏輯嚴謹，有條不紊，娓娓道來。

而壞的代碼，猶如病毒，它不僅癱瘓你的程序，還有很強的傳播效應，等到它擴散開來，神仙難治。

壞的代碼，像一個泥團，閱讀的時候，你仿佛被困于黑暗的迷宮，又仿佛在跟一個絮絮叨叨的人交談，他的腦回路經常短路，說話含混不清，主次不分，叨逼半天，你依然get不到他的中心思想，你常常感覺智商受到了莫大的侮辱，你面露艱難神色，心中萬馬奔騰。

有很多區分好壞代碼的規則，我也看過一些，對于文章中提到的一些標準做法，就不重復嚼舌頭根子了，我想結合自己的工作經歷，談一談自己的切身體會。

閑扯半日，言歸正傳，要編寫彌漫好味道的代碼，要遵循哪些約束和指引呢？

一致性

持之以恒的遵從一致性規則，在代碼風格上，爭論個三天三夜估計也定不出個好壞出來，但好的風格一定是強一致性的，這一點應該比較容易達成一致吧?風格的好壞其實更多受習慣的影響，頭發少一點的程序員應該都有自己風格變遷的經歷，多年前自己篤信不疑的Good Style或許正是當前深惡痛絕的Bad Style，所以我主張在Style上擱置嘴炮，一個項目應該有一個編碼規則，好的規則應該是以理服人的，好的規則應該是拒絕任性夾帶私貨的，規則定了之后，就遵照執行吧，可能某個風格跟你不相符，但沒關系，你要知道，這并不意味，你在style之戰敗下陣來，也并不表示它說服了你，你遵守的是規則和紀律本身。

我經歷過一些c的項目，函數命名有大駝峰，有小駝峰，有下劃線連詞，還有駝峰加下劃線（有些是兩個），還有函數名下劃線或者兩個下劃線開頭，總結一下它的規律就是沒有規律，非常隨心所欲，令我莫衷一是。

變量（包括文件、類/結構體、函數）命名，比如ohmygod，你可能搞不清哪些字母是一伙的，所以需要界定單詞。駝峰通過單詞首字母大寫來界定單詞，另一個慣用做法是用下劃線拼接單詞。駝峰的弊端是丑，下劃線拼接的弊端是增加了標識符長度（相比首字母大寫），好處是跟std c/c++、linux kernel的做法一致，喜歡kernel的碼農容易找到如家般的歸屬感。

c++有namespace避免沖突，c 經常用prefix防止命名污染全局空間，但我認為命名簡潔扼要很重要，所以我支持簡短的前綴而反對冗長的前綴。

代碼密度

實現同樣的功能，你喜歡100行代碼，還是20行代碼？如果貴司不以代碼行數考核績效，我建議你把代碼寫的精簡，而如果貴司以代碼行數考核績效，我建議你離職，開滴滴，送外賣或者擺攤都行，因為在這種公司耗費青春基本上也不會有什么發展前途。

把簡單的東西搞復雜化很容易，你只需要找一個能力平庸的人就能實現化簡為繁的愿望，而化繁為簡則堪稱化腐朽為神奇。也許你要說，我欠缺簡化的能力，這并不奇怪，坦白講，這不是一件容易的事，你做不到沒關系，但你擁有正確的理念更重要，它將幫助你認清前進的方向，而不是在錯誤的道路上越走越遠。

有些項目，充斥各種無效代碼，其實你只需要稍加思考，你就能識別出來。

比如大塊注釋掉的代碼像發臭的尸體一樣遍布其中。比如大量功能重復的代碼像垃圾一樣堆砌在那里。

比如本不需要返回值的函數，執拗的固定返回true，然后在調用的地方還要裝模作樣的check一下返回值，如果返回false，再記一條日志，再assert一下，再拋個異常，這樣顯得很有職業操守，美其名曰面向failed編程，處理了各種異常情況。

又或者函數一進來，不管三七二十一，對入參一頓無腦檢查，一頓操作猛如虎，一看代碼二百五，宣稱這是符合ISO XX標準的安全做法，全然忘記你在編寫的是一個私有實現函數，你在調用它之前已經檢查過一遍，私有函數是一個受控的安全上下文，這不僅不優雅而且不綠色（低效耗電）并且不安全（在該崩的時候沒崩把雷埋到了更隱蔽的地方），話說你看標準庫函數strcpy/strcat，vector operator[]檢查傳參了嗎？

提高代碼密度或者說濃度有利于理清思路，有利于突出重點，有利于提高維護性，而充斥各種無效語句的代碼只會把關鍵語句淹沒在汪洋大海，使得review代碼的人get不到重點，看不清主次。像聽一個絮絮叨叨的人做報告，滿篇廢話，像看一個劇情拖沓的連續劇，昏昏欲睡，像喝一瓶二鍋頭兌十斤白開水，口能淡出個鳥來。

重構是程序員的口頭禪，重構是在保持程序功能不變的情況下調整架構和實現，我認為提高代碼密度應作為重構的一項追求。

linux kernel、lua、nginx、skynet 這些優秀的開源庫代碼濃度都很高，建議讀者朋友品嘗一下。

封裝

我們最常干的一件事就是把重復編寫的代碼封裝到一個函數里去，用多處調用替代重復編寫，這個很好理解，但其實即使不被多處調用，把相關的一段代碼封裝到一個實現函數也是有必要的，因為把代碼平鋪開來，把細節暴露出來，容易掩蓋重要的東西，即框架和脈絡會變得不夠清晰。

一個見名知義的函數調用比堆砌在那里的一段代碼給我的感受好，我如果關心它是怎么做的，我可以跳轉到定義看看實現。

封裝的一個核心原則是單一職責，符合單一職責的函數更易于被復用。

解耦

構建松散耦合的系統一直是軟件工程的一個目標，模塊化的一個方向便是解耦，但我們口口聲稱心心念想的解耦，在實施層面又有幾分體現呢？

比如，我們經常干的一件蠢事就是把類似配置文件，或者宏定義的東西集中的一個頭文件里去，看起來很統一也很正規，起碼我之前也是這樣認為的，但忽然有一天，發現自己這樣做顯得很不聰明的樣子，為什么呢？因為你想把所有模塊配置相關的東西都塞進配置公共文件真的合適嗎？是不是把公共接口抽離出來更好，把配置相關的數據下沉到各模塊更合適？

另外，把宏都定義到一起，這意味隨便改點東西，都會需要修改宏頭文件，而這個頭文件就會成為程序世界的中心，修改公共宏文件幾乎會引起整個系統的所有源文件rebuild，這簡直就是AOE團滅啊。所以更好的方式是分而治之，去集中式。

我們知道c/c++的編譯單元是source file（.c/.cpp），編譯的第一步是預處理，所有include都會展開替換，所以我們要避免引入任何不必要的頭文件，也應該把本編譯單元用到的頭文件都include進來，這就是所謂的頭文件自給自足。這點很重要，但很多人會不以為然，甚至有些人會搞一個allincluded.h，把常用的一些頭文件全部include進來，然后自認為一勞永逸的完美的解決了問題，包含不必要的頭文件會增加編譯時間，會增加依賴，我們不僅應該避免錯誤的包含，還應該精心設計和劃分文件，使得每個文件的功能足夠內聚單一。

縮寫

慎用縮寫，相比縮寫帶來的含混不清，我寧愿多敲幾下鍵盤，如果要縮寫請符合慣例遵從常規，比如AI，比如App，比如cfg，但是你把threshold縮寫成threshod，把Item縮寫成Iem，我特木真的搞不懂你是拼錯了還是縮錯了？

遵從標準

我遇到過一些項目，每個模塊單獨定義自己的int32，float，char，void，比如定義MoKuaiA_int32，MoKuaiB_int32，MoKuaiC_CHAR，不僅如此，它還把inline，true，false，VOID，const，case，static等一眾關鍵字全部redefine了，令人匪夷所思的是它竟然把標準C API全部重定義一遍，令人發指的是它竟然不讓你用語言的標準寫法。

我一直搞不懂為什么要這樣做？如果你只是需要解決不同體系結構下long等整型的長度差異，我想偷偷告訴你，c庫頭文件stdint.h已經從標準層面統一解決了這個問題，里面int8_t/16_t/32_t/64_t，還有uint8_t等等應有盡有。

這樣的做法是很不好的，會讓符合標準的寫法寸草不生，建議不要這么做。

宏

宏是c的一個有效武器，在有些情況下確實行之有效，我是宏的中間派，我既反對禁用宏，也反對濫用宏，inline可以部分替代宏，但不能完全替代宏。

但我見過一些項目，到處都是宏，全大寫，至少1/3的代碼都是各種花里胡哨的宏，你review代碼的時候，不停的跳來跳去，看了一眼，哦，就這樣啊，然后切回來，頻繁的上下文切換是低效的，它打斷了你的思路，讓你看代碼有種撒尿撒到一半憋回去的感覺。其實很多時候完全沒有必要，不需要整這些虛頭巴腦的。

命名

命名有一些指引，比如類/結構體應該用名詞，函數應該用類似動詞或者doSomething這樣的動賓結構，這些規矩都是耳熟能詳的。

我主張命名應該簡明扼要，不要羅里吧嗦，要準確的表達出它要做的事情，如果你碰到命名困難，你可能需要考慮你的類定義或者接口劃分是否合適。

命名是接口的一部分，很重要，好的命名是自注釋的。

如果你沒有思路，那我建議你參考一下STD C/C++ API，畢竟這些接口歷經幾十年沒有大的變化，算是經受住了歷史的考驗，比如malloc/free/atoi，stl 容器的成員函數也有點意思：size(), capacity()，resize()，reserve()，push()，pop()，top()，back()，很干脆，不廢話，我覺得很好。

所以，如果你編寫的是某某管理器，比如ItemManager，我建議你直接取名add()，remove()，而不用AddItem()，RemoveItem()，因為你本身就是Item的Manager，操作的必然是Item，而且從參數上也能體現出來，少即是多，多不如少。

擴展性

開閉原則是應對擴展性的rule，人無遠慮必有近憂，說的是我們不能局限于眼前，但也請不要盲目迷信擴展性，戲太多也是病。

知乎有一篇神貼講的是如何把helloworld搞成一個big project，當你想給別人項目挑刺的時候，你可以用擴展性說事，但我建議你少說。

避免特例

linus大神分享過他心中的好代碼，說的是針對鏈表的操作，他更喜歡統一性的處理方式，而不是做特例化的處理，我想這個例子很有代表性，它其實代表一種理念，那就是自始至終，我們的頭腦里必須優先考慮normal化的處理方式，當然這其實是一個比較高層次的要求，菜鳥互啄可以先跳過這一層要求。

高效而魯棒

有很多避免運行低效的做法，比如減少拷貝，提高局部性，buffer/cache，空間時間置換，內聯，分支預測，判斷前置，計算延遲，無鎖技術。

提高魯棒性的關鍵是面向failed編程，不信任/零信任設計，假設依賴的上下文，上下游都是不可靠的，方法很多，不一一列舉了。

最后

噴了這么多，也給大家一次噴作者的機會，貼出來自己的代碼：https://github.com/ZhuanJia/mynet，這是13年剛進福廠時候周末自己搗鼓的玩具，它或許有這樣那樣的問題，如果你覺得不錯，請給我點贊，如果你覺得很水，那我可以甩鍋給時間，畢竟7年前寫的嘛。有句話說過，如果你不覺得一年前的自己是傻逼，那說明你這一年沒什么進步，何況7年前呢。

推薦閱讀

• 干貨 | 大白話徹底搞懂 HBase RowKey 詳細設計

• 那天我去逛街，發現連大編程語言都擺起地攤了……
  

• 研發的未來在哪里？Serverless 云開發來了！

• Facebook 公司：如何清除 960 萬句“臟話”？

• Linux 之父怒刪工程師提交的補丁，稱“太蠢了”網友：懟得好！

• 干貨！3 個重要因素，帶你看透 AI 技術架構方案的可行性！

• 熱評 | 警惕新基建熱潮中的區塊鏈項目爛尾

真香，朕在看了！

總結

以上是生活随笔為你收集整理的趣谈程序员真香定律：源码即设计的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。