大牛的代碼是這樣寫的

ad6623 發(fā)布于2019-08-19 11:39 / 3630人閱讀

摘要：在公司，一般都會有公司規(guī)定的若干規(guī)范，在編碼時，時刻提醒要遵循這些規(guī)范，命名規(guī)則縮進規(guī)則換行規(guī)則團隊不分大小，哪怕是個人獨立項目，風格統(tǒng)一的代碼，是確保代碼可讀性的前提。

什么樣的代碼才是好代碼

**遵循規(guī)范
有意義的命名
足夠短的方法體
無歧義的行為**
一篇好的代碼，就如同一篇好的文章，結(jié)構(gòu)合理，重點清晰，通俗易懂。積累了足夠多的編碼經(jīng)驗，在完成功能之余，自然會追求自己的代碼更“好看”一些，接下來就談?wù)勎覍τ凇昂么a”的理解。

遵循規(guī)范

沒有規(guī)矩，不成方圓，遵循編碼規(guī)范，是最基本的素養(yǎng)。在公司，一般都會有公司規(guī)定的若干規(guī)范，在編碼時，時刻提醒要遵循這些規(guī)范，命名規(guī)則、縮進規(guī)則、換行規(guī)則……團隊不分大小，哪怕是個人獨立項目，風格統(tǒng)一的代碼，是確保代碼可讀性的前提。

如果實在不知道應(yīng)該遵循怎樣的編碼規(guī)范，不妨找找看語言官方是否有推薦的規(guī)范說明，比如C#，微軟官方就提供了一套編碼規(guī)范。或者，我們可以找某個大公司的編碼規(guī)范，這些規(guī)范一般都是經(jīng)過了實際項目實踐過的，可以放心使用。

養(yǎng)成了習慣之后，代碼就如同學生時代寫作文那樣，無論內(nèi)容好壞，首先“卷面分”是能拿到的。

有意義的命名

為你的類、方法、變量選擇有意義的命名，相信我，這非常重要，好的代碼應(yīng)該是“自解釋”的，不僅可以提高代碼可讀性，也提高了可維護性。假如，僅僅半年后再讀自己的代碼時，看著滿篇莫名其妙的名稱，連代碼要實現(xiàn)什么業(yè)務(wù)邏輯都想不起來了，能做的就只有懷疑人生了吧。

類的命名，應(yīng)該體現(xiàn)出“是什么”。比如一個提供文件讀寫功能的類，叫做 FileAccessor 就比 FileHelper 好一些，當然或許分解成 FileWriter 和 FileReader 更適合，但這要視需求而定。

方法的命名，應(yīng)該體現(xiàn)出“做什么”，描述這個方法實際做了什么處理。比如我們有一個根據(jù)名稱排序的方法，那么叫做 SortByName 就比簡單的 Sort 擁有更好的可讀性。

變量的命名，如同類，也應(yīng)該體現(xiàn)“是什么”。比如一個保存文件完整路徑的變量，叫做 a 的話，簡直是反人類，叫做 f 好歹能讓我猜想這是個有關(guān) file 的變量，如果叫做 filePath 我給90分，如果是 fileFullPath 我就給滿分。

足夠短的方法體

一旦一個方法寫得太長，勢必堆積了大量的邏輯，一旦涉及到很多嵌套或者邏輯分支，不說將來的維護難度，就是當下，很容易就把自己也繞懵了吧。

所以一旦法相一個方法體過長，就應(yīng)該考慮是否需要把一個完整的邏輯段提取成一個獨立私有方法了，這樣以來，不僅縮短了單個方法的長度，讓邏輯更加清晰，也可以有效的降低風險，因為簡短代碼的邏輯復(fù)雜度勢必降低，開發(fā)人員更容易把握住。

至于“過長”是多長呢？根據(jù)個人經(jīng)驗，25行就值得引起注意了，50行基本就是可忍受的上限了，除非及特殊情況，否則盡量不要超過這個上限。曾經(jīng)維護過單個方法2000多行的人瑟瑟發(fā)抖，往事不堪回首。

無歧義的行為

具有隱含行為的方法，危害極大。一個方法，盡量只做一個事情，不要做額外的事，否則很容易帶來意想不到的風險。

舉個例子，我自己寫過的一個方法。基本數(shù)據(jù)結(jié)構(gòu)類似堆棧，每次從集合中取出一個對象之后，將這個對象移出集合。但是我的方法名稱是 GetXXX，結(jié)果就是發(fā)現(xiàn)每次取一個對象之后，集合莫名其妙（其實業(yè)務(wù)就是這樣沒錯，但是我不記得這回事兒了）地就會變短，導(dǎo)致后續(xù)的處理一塌糊涂。對策有兩種，一是把對象移出集合的邏輯拿到 GetXXX 的調(diào)用處來做，這樣移除動作就是顯示可見的了；或者把方法名改成 PopXXX 或者 GetAndRemoveXXX （丑了點，但好歹看得懂），這樣以來，至少我們的行為與名稱是一致的，消除了歧義。

以上只是簡單列舉了一些最基本的準則，希望對同樣希望寫出“好代碼”的同行有幫助，感謝閱讀。