每個程序員只要不犯錯，都能寫出機器能看得懂的代碼，程序能正常跑起來，自然就意味著機器正常識別了程序。
但是，真正牛逼的程序員是寫出能讓人看得懂的代碼。
不要小看這個，雖說我們寫的代碼確實是跑給機器的，但是代碼是人寫的，而通常一個項目的開發(fā)，需要多個程序員一同協(xié)助開發(fā)，這時能寫出 human readble 的代碼就顯得至關(guān)重要，因為不僅可以減少后期維護的時間成本，而且還能讓后面加入的新同事能更快的上手項目。
要能寫出干凈、整潔并讓人易懂的代碼，必然離不開一些規(guī)則，只要自覺遵守、合理運用這些規(guī)則，代碼通常都不會太差。
事實上，每個公司或者開源項目都有各自的編碼風格指南文檔，這些文檔無不例外都羅列了十幾個、上百個的條款，基本上都是干干巴巴的示例和說明，不說能不能看完， 即使看完了，也都忘了差不多，非常容易被勸退。
這次，我就從中抽離幾個重要的條款，以及結(jié)合我工作的經(jīng)驗，把寫出好的 code style 的幾個注意事項跟大家說下。
只要注意代碼格式、變量命名和注釋三個方面，代碼的“顏值”起碼提高 80%。
往大的說，能寫出“高顏值”的代碼的人，也能從這個小事反映出他是一個細心的人，同時也具備責任感，只要把每一件小事做好、做到極致，漸漸的，你的同事和上級就會對你產(chǎn)生信任感。
代碼格式
第一眼看代碼就是看代碼的整體格式，好的代碼格式，一眼就能讓人感到清爽、舒服，我們本身每天工作就比較繁忙了，還要面對亂糟糟的代碼格式，心情肯定差到極點，感覺像是吃了一坨 shi。
文章也是一樣，小林我也很注重文章的排版，我的排版也被很多讀者夸贊過，不用追求花里胡哨的裝飾，只要保持簡潔、大方就行，雖說文章是我寫的，但是文章是給別人看的，那我肯定要為讀者的“眼睛”負責呀。
一個好的代碼格式，只需要遵循五個字，那就是「留白的藝術(shù)」。
代碼和文章，不要為了節(jié)約篇幅，把一大坨東西“擠”在一起，這樣只會給人家?guī)韷浩雀小?/span>
多運用空格和換行，用空格分隔開變量與操作符，用空行分割開代碼塊。
說了那么多口水話，接下來上點實際代碼例子。
來，我上一大坨的代碼給大家看看：
是不是很密集？看的很難受？壓迫感++ 是不？
什么？你說你沒感覺，那你被我逮到了，你肯定是經(jīng)常寫這類車禍現(xiàn)場代碼的兇手，搞崩團隊心態(tài)的發(fā)動機。
運用好「留白的藝術(shù)」，代碼就變成下面這樣：
是吧，只需簡單運用空格和空行，代碼就顯得很清爽，段落層次分明，讀起來不會太累，也更加容易理清代碼的邏輯。
所以，敲代碼的同時，別忘了用空格和空行“裝飾”下你的代碼，你的每一處留白，都是在拯救別人的眼睛。
變量命名
不知道你是不是寫過變量名為，a、b、c、d...的代碼，如果代碼只是你測試用的，那也問題不大，但是我不信在你把代碼越寫越多后，還記得這些變量的作用。同樣，也不要在一個多人維護的項目里，干出這樣的事情，你十有八九會被同事孤立。
給變量命名是有講究的，不是隨意的，取的名字應該是讓人知道該變量的作用，減少大家根據(jù)上下文才猜測的時間。
命名最好以英語的方式描述，而不要漢語拼音，英語詞匯不過關(guān)也沒事，敲代碼本身就是一個“開卷考試”的事情，打開瀏覽器，隨意都能在各種翻譯網(wǎng)站找到合適的英語詞匯。
另外，有一些變量名在程序員之間已經(jīng)形成了普遍共識，這些都是可以直接使用的，比如：
-
用于循環(huán)的i/j/k； -
用于計數(shù)的count； -
表示指針的p/ptr； -
表示緩沖區(qū)的buf/buffer； -
表示總和的sum； -
…
對于變量命名的風格，一般應用比較廣泛的有三種。
第一種風格叫「匈牙利命名法」，早期是由微軟的一個匈牙利人發(fā)明的，當時 IDE 并沒有那么智能，識別不出變量的類型，代碼量一大起來，要確定一個變量的類型是個麻煩的事情，于是就要求使用變量類型的縮寫作為變量名的前綴字母，代碼例子如下圖：
但是這個風格在面臨代碼重構(gòu)時，就是一個災難了，因為如果更換了變量的類型，那么還得把變量名也全部改過來，所以這種風格基本被淘汰了。
不過它里面還有一種做法還是不錯的，對于有作用域的變量會加上對應的前綴來標識，給成員變量加 m_前綴，比如 m_count，給全局變量加 g_前綴，比如 g_total，這樣一看到前綴就知道變量的作用域了，很清晰明了。
第二種風格叫「駝峰式命名法」，主張單詞首字母大寫，從而形成駝峰式的視覺，對于變量的首字母有的要求是小寫，有的要求是大寫，比如 myName、MyAge。這種風格在 Java 語言非常流行，但在 C/C++ 語言里用的比較少。
第三種風格叫「下劃線命名法」，變量名用的都是小寫，單詞之間用下劃線分割開，比如 my_name、my_age，這種風格流行于 C/C++ 語言。
這些風格也不是說只能固定只能用一種，我們可以結(jié)合一起使用的，我常用的語言是 C/C++，我對自己一般有以下這幾個規(guī)則：
-
變量名、函數(shù)名用下劃線命名風格，對于有作用域的變量，也會使用前綴字母來標識，比如成員變量用m_、全局變量用 g_、靜態(tài)變量用 s_；
-
類的名字用駝峰式命名風格，比如 VideoEncode、FilePath;
-
宏和常量用全大寫，并用下劃線分割單詞，比如 MY_PATH_LEN；
下面用實際代碼作為例子：
關(guān)于變量命名還有一個問題是，名字的長度如何才是合理的。
有一個普遍被大家認可的原則是：名字越長，它的作用域應越廣。也就是說，局部變量的名字可以短一些，全局變量的名字可以長一些。
注釋
留白的藝術(shù)用上，變量名規(guī)范也用上，讓每個人都能一眼看懂的代碼，還差點東西，那就是注釋。
注釋存在的原因就是為了讓人快速理解代碼的邏輯，一個好的注釋，是能讓人只看注釋就知道代碼的意圖。
我猜大家注釋也寫了不少，注釋一般是用來闡述目的、用途、工作原理、注意事項等等，注釋必須要正確、清晰、言簡意賅，而且在修改代碼邏輯時，也別忘記了要更正注釋，否則就會誤導人了。
注釋最好寫明作者、時間、用途、注意事項這四個信息，比如下面這個例子：
注釋用中文好還是英文好呢？
當然是英文比較好，因為英文在 ASCII 或 UTF-8 編碼格式里兼容性很好，而中文可能會在導致在一些編碼格式里顯示亂碼，亂碼了就自然失去注釋的作用了。
注釋最好也要統(tǒng)一使用一個標準格式，比如 Java 語言一般是使用 Javadoc 注釋標準，遵循該標準后，會有專門的工具可以一鍵生成 API 文檔。
當然，除了給代碼、函數(shù)、類寫好注釋，文件頂部位置也可以寫上對該文件的注釋，信息一般是版權(quán)聲明、更新歷史、功能描述等。
比如下面這個，是比較常用注釋文件的一種標準：
再來，如果你發(fā)現(xiàn)某個地方的代碼有改進或未實現(xiàn)的地方，而暫時沒有時間去修改的時候，可以使用 TODO來標識它，這樣代碼需要優(yōu)化的時候，直接搜索這個關(guān)鍵詞就可以了，也可以給將來的維護者一個提醒。比如：
注釋要寫的好，得要有換位思考的思維，想著寫怎么樣注釋能讓那些沒有參與過該項目開發(fā)的人能最快速的理解，以便能加快他們?nèi)谌朐擁椖康乃俣取?/span>
總結(jié)
要寫出高顏值的代碼，離不開良好的編程習慣，今天主要提了三個重要點：
-
留白藝術(shù)的妙處，多運用空格和空行；
-
變量名、函數(shù)名、類名要起個讓人容易理解的名字；
-
注釋要寫好，多換位思考，最好也要遵循一些注釋標準，便于自動生成 API 文檔；
免責聲明：本文內(nèi)容由21ic獲得授權(quán)后發(fā)布，版權(quán)歸原作者所有，本平臺僅提供信息存儲服務。文章僅代表作者個人觀點，不代表本平臺立場，如有問題，請聯(lián)系我們，謝謝！
下載文檔
