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