每個程式設計師只要不犯錯，都能寫出機器能看得懂的程式碼，程式能正常跑起來，自然就意味著機器正常識別了程式。

但是，真正牛逼的程式設計師是寫出能讓人看得懂的程式碼。

不要小看這個，雖說我們寫的程式碼確實是跑給機器的，但是程式碼是人寫的，而通常一個專案的開發，需要多個程式設計師一同協助開發，這時能寫出 human readable 的程式碼就顯得至關重要，因為不僅可以減少後期維護的時間成本，而且還能讓後面加入的新同事能更快的上手專案。

要能寫出乾淨、整潔並讓人易懂的程式碼，必然離不開一些規則，只要自覺遵守、合理運用這些規則，程式碼通常都不會太差。

事實上，每個公司或者開源專案都有各自的編碼風格指南文件，這些文件無不例外都羅列了十幾個、上百個的條款，基本上都是乾乾巴巴的示例和說明，不說能不能看完， 即使看完了，也都忘了差不多，非常容易被勸退。

這次，我就從中抽離幾個重要的條款，以及結合我工作的經驗，把寫出好的 code style 的幾個注意事項跟大家說下。

只要注意程式碼格式、變數命名和註釋三個方面，程式碼的“顏值”起碼提高 80%。

往大的說，能寫出“高顏值”的程式碼的人，也能從這個小事反映出他是一個細心的人，同時也具備責任感，只要把每一件小事做好、做到極致，漸漸的，你的同事和上級就會對你產生信任感。

程式碼格式

第一眼看程式碼就是看程式碼的整體格式，好的程式碼格式，一眼就能讓人感到清爽、舒服，我們本身每天工作就比較繁忙了，還要面對亂糟糟的程式碼格式，心情肯定差到極點，感覺像是吃了一坨 shi。

文章也是一樣，小林我也很注重文章的排版，我的排版也被很多讀者誇讚過，不用追求花裡胡哨的裝飾，只要保持簡潔、大方就行，雖說文章是我寫的，但是文章是給別人看的，那我肯定要為讀者的“眼睛”負責呀。

一個好的程式碼格式，只需要遵循五個字，那就是「留白的藝術」。

程式碼和文章，不要為了節約篇幅，把一大坨東西“擠”在一起，這樣只會給人家帶來壓迫感。多運用空格和換行，用空格分隔開變數與操作符，用空行分割開程式碼塊。

說了那麼多口水話，接下來上點實際程式碼例子。

來，我上一大坨的程式碼給大家看看：

是不是很密集？看的很難受？壓迫感++ 是不？

什麼？你說你沒感覺，那你被我逮到了，你肯定是經常寫這類車禍現場程式碼的凶手，搞崩團隊心態的發動機。

運用好「留白的藝術」，程式碼就變成下面這樣：

是吧，只需簡單運用空格和空行，程式碼就顯得很清爽，段落層次分明，讀起來不會太累，也更加容易理清程式碼的邏輯。

所以，敲程式碼的同時，別忘了用空格和空行“裝飾”下你的程式碼，你的每一處留白，都是在拯救別人的眼睛。

變數命名

不知道你是不是寫過變數名為，a、b、c、d... 的程式碼，如果程式碼只是你測試用的，那也問題不大，但是我不信在你把程式碼越寫越多後，還記得這些變數的作用。同樣，也不要在一個多人維護的專案裡，幹出這樣的事情，你十有八九會被同事孤立。

給變數命名是有講究的，不是隨意的，取的名字應該是讓人知道該變數的作用，減少大家根據上下文才猜測的時間。

命名最好以英語的方式描述，而不要漢語拼音，英語詞彙不過關也沒事，敲程式碼本身就是一個“開卷考試”的事情，開啟瀏覽器，隨意都能在各種翻譯網站找到合適的英語詞彙。

另外，有一些變數名在程式設計師之間已經形成了普遍共識，這些都是可以直接使用的，比如：

• 用於迴圈的 i/j/k；
• 用於計數的 count；
• 表示指標的 p/ptr；
• 表示緩衝區的 buf/buffer；
• 表示總和的 sum；
• …

對於變數命名的風格，一般應用比較廣泛的有三種。

第一種風格叫「匈牙利命名法」，早期是由微軟的一個匈牙利人發明的，當時 IDE 並沒有那麼智慧，識別不出變數的型別，程式碼量一大起來，要確定一個變數的型別是個麻煩的事情，於是就要求使用變數型別的縮寫作為變數名的字首字母，程式碼例子如下圖：

但是這個風格在面臨程式碼重構時，就是一個災難了，因為如果更換了變數的型別，那麼還得把變數名也全部改過來，所以這種風格基本被淘汰了。

不過它裡面還有一種做法還是不錯的，對於有作用域的變數會加上對應的字首來標識，給成員變數加 m_ 字首，比如 m_count，給全域性變數加 g_ 字首，比如 g_total，這樣一看到字首就知道變數的作用域了，很清晰明瞭。

第二種風格叫「駝峰式命名法」，主張單詞首字母大寫，從而形成駝峰式的視覺，對於變數的首字母有的要求是小寫，有的要求是大學，比如 myName、MyAge。這種風格在 Java 語言非常流行，但在 C/C++ 語言裡用的比較少。

第三種風格叫「下劃線命名法」，變數名用的都是小寫，單詞之間用下劃線分割開，比如 my_name、my_age，這種風格流行於 C/C++ 語言。

這些風格也不是說只能固定只能用一種，我們可以結合一起使用的，我常用的語言是 C/C++，我對自己一般有以下這幾個規則：

• 變數名、函式名用下劃線命名風格，對於有作用域的變數，也會使用字首字母來標識，比如成員變數用m_、全域性變數用 g_、靜態變數用 s_；
• 類的名字用駝峰式命名風格，比如 VideoEncode、FilePath;
• 巨集和常量用全大寫，並用下劃線分割單詞，比如 MY_PATH_LEN；

下面用實際程式碼作為例子：

關於變數命名還有一個問題是，名字的長度如何才是合理的。

有一個普遍被大家認可的原則是：名字越長，它的作用域應越廣。也就是說，區域性變數的名字可以短一些，全域性變數的名字可以長一些。

註釋

留白的藝術用上，變數名規範也用上，讓每個人都能一眼看懂的程式碼，還差點東西，那就是註釋。

註釋存在的原因就是為了讓人快速理解程式碼的邏輯，一個好的註釋，是能讓人只看註釋就知道程式碼的意圖。

我猜大家註釋也寫了不少，註釋一般是用來闡述目的、用途、工作原理、注意事項等等，註釋必須要正確、清晰、言簡意賅，而且在修改程式碼邏輯時，也別忘記了要更正註釋，否則就會誤導其他人了。

註釋最好寫明作者、時間、用途、注意事項這四個資訊，比如下面這個例子：

註釋用中文好還是英文好呢？當然是英文比較好，因為英文再 ASCII 或 UTF-8 編碼格式裡相容性很好，而中文可能會在導致在一些編碼格式裡顯示亂碼，亂碼了就自然失去了註釋的作用了。

註釋最好也要統一使用一個標準格式，比如 Java 語言一般是使用 Javadoc 註釋標準，遵循該標準後，會有專門的工具可以一鍵生成 API 文件。

當然，除了給程式碼、函式、類寫好註釋，檔案頂部位置也可以寫上對該檔案的註釋，資訊一般是版權宣告、更新歷史、功能描述等。

比如下面這個，是比較常用註釋檔案的一種標準：

再來，如果你發現某個地方的程式碼有改進或未實現的地方，而暫時沒有時間去修改的時候，可以使用 TODO 來標識它，這樣程式碼需要優化的時候，直接搜尋這個關鍵詞就可以了，也可以給將來的維護者一個提醒。比如：

註釋要寫的好，得要有換位思考的思維，想著寫怎麼樣註釋能讓那些沒有參與過該專案開發的人能最快速的理解，以便能加快他們融入該專案的速度。

總結

要寫出高顏值的程式碼，離不開良好的程式設計習慣，今天主要提了三個重要點：

• 留白藝術的妙處，多運用空格和空行；
• 變數名、函式名、類名要起個讓人容易理解的名字；
• 註釋要寫好，多換位思考，最好也要遵循一些註釋標準，便於自動生成 API 文件；