關於代碼的可讀性淺談

關於可讀性話題的探討可謂是歷久彌新，從古至今，人們一直在探尋着如何可以把自身的知識、經驗可以更好的傳播下去，越簡單易懂，傳播速度也快，這也是一種書面表達能力的體現。

本文將主要探討一下代碼的可讀性。

爲何研究可讀性？

《重構》一書中曾說過，惟有優秀的程序員纔可以寫出人類能理解的代碼。軟件的規模愈來愈大，一個系統一般須要幾代程序員來開發維護。然而這些程序員們每每都素未謀面，只能「神交」於代碼的字裏行間。可見，代碼的可讀性的重要性，也是一個優秀程序員的標誌。

關於可讀性的誤區

在程序開發的大流中，相信每一個人都曾吐槽過他人代碼的難以理解，設計之差，然而一味吐槽他人而忽略自身的問題也將走入另外一個誤區，也就是忽視自身理解力的提升。所以，在咱們努力提高自身代碼可讀性的同時，一樣也要提高自身的理解力，多讀他人代碼，吸收他人經驗教訓，才能成長的更快！

寫得出好代碼，也看的懂爛代碼（若是過於爛則另當別論），纔是高手！

提升可讀性的方法

（一）統一的命名規範。在市面上的大多數項目組中，都是有統一的命名規範的，只是規範略有不一樣而已。統一的規範可讓代碼整齊劃一像一我的所寫的同樣，你們讀本身的代碼固然效率更高，也更容易理解他人的想法。好的規範必定程度上也能夠避免新手程序員犯錯。關於命名規範的介紹：

<1>變量的命名。變量用來指定數據，因此最好的結構應該是[形容詞+名詞]，經常使用的變量命名規範有匈牙利命名法、駱駝命名法、帕斯卡命名法、網上資料不少，可參考https://baike.baidu.com/item/%E5%8F%98%E9%87%8F%E5%91%BD%E5%90%8D%E8%A7%84%E5%88%99/4084105?fr=aladdin；

<2>函數的命名。函數經常指行爲，因此最好用[動詞+形容詞+名詞+狀態]，命名同變量命名；

<3>類的命名。一般接口前加個I,枚舉前加個E，結構體有S開頭，等方式，幫助你們更快的識別類型，提升效率；

<4>命名必定要爲有意義的命名。有意義的命名就像註釋同樣，幫助他人更高效的理解程序想表達的思想；

<5>給數字賦予含義。避免在程序中直接出現數字，用有意義的變量名代替，能極大下降閱讀成本，不然，代碼中忽然出現，15,37,等數字，你能知道是什麼鬼不；

<6>爲他人編碼。關於命名的描述，更多的是讓其餘讀者更容易理解代碼的含義，開發過程當中，多站在他人的角度思考下問題，多思考本身讀他人代碼時遇到的坑，這樣編寫出的代碼可讀性纔會更高，協做的效率才能更高。

（二）關於函數的設計

<1>函數體的大小最好在100行以內,這樣在編輯過程當中一般能夠用一屏顯示完整個函數，更容易全局的瞭解函數。反之，函數過大，可能夾雜了過多的邏輯，不符合低耦合的思想，他人在閱讀的時候也必須反覆滾動視圖才能瞭解整個函數的功能，效率大大下降；

<2>將條件判斷放在開頭，邏輯放在最後。開發過程當中，爲了程序的健壯性，每每須要加入許多數據正確性驗證，來提升代碼的健壯性。將這部分代碼放至開頭，代碼會更聚合，優雅，同時他人閱讀時也能夠統一略過，直奔邏輯，提升效率；

<3>減小嵌套。多層相似for的循環，每每是編程過程當中的又一大坑，隨着嵌套的增長，可讀性曾指數型降低，更容易把本身繞暈，產生錯誤。把子循環封裝成函數來解決它。同時在循環中，常會遇到一些狀況，就會break，或continue,這部分挪到循環的開頭，理由相似<2>條。

<4>可讀性與耦合性。耦合性越低，內聚性越高的模塊可讀性天然會更好，由於邏輯設計集中，讀者心無旁騖，專一於單一功能。如何下降耦合性。http://www.javashuo.com/article/p-yrrpvwzi-gz.html

不讀會後悔的話

優雅的代碼，經常給人以美的感覺，在幫助他人閱讀的同時，也是自身邏輯清晰的體現。你們的可讀性都高了，團隊的協做效率天然也會提升。細節決定成敗，願你注意開發中的每一個細節，聚沙成塔，成就大我！

持續總結完善中，強烈歡迎你們給出有效建議，共同改進~~~