每個程序員只要不犯錯，都能寫出機器能看得懂的代碼，程序能正常跑起來，自然就意味着機器正常識別了程序。
但是，真正牛逼的程序員是寫出能讓人看得懂的代碼。
不要小看這個，雖說我們寫的代碼確實是跑給機器的，但是代碼是人寫的，而通常一個項目的開發，需要多個程序員一同協助開發，這時能寫出 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 文檔；