大牛的代碼是這樣寫的

什麼樣的代碼纔是好代碼

**遵循規範
有意義的命名
足夠短的方法體
無歧義的行爲**
一篇好的代碼，就如同一篇好的文章，結構合理，重點清晰，通俗易懂。積累了足夠多的編碼經驗，在完成功能之餘，天然會追求本身的代碼更「好看」一些，接下來就談談我對於「好代碼」的理解。

遵循規範

沒有規矩，不成方圓，遵循編碼規範，是最基本的素養。在公司，通常都會有公司規定的若干規範，在編碼時，時刻提醒要遵循這些規範，命名規則、縮進規則、換行規則……團隊不分大小，哪怕是我的獨立項目，風格統一的代碼，是確保代碼可讀性的前提。

若是實在不知道應該遵循怎樣的編碼規範，不妨找找看語言官方是否有推薦的規範說明，好比C#，微軟官方就提供了一套編碼規範。或者，咱們能夠找某個大公司的編碼規範，這些規範通常都是通過了實際項目實踐過的，能夠放心使用。

養成了習慣以後，代碼就如同窗生時代寫做文那樣，不管內容好壞，首先「卷面分」是能拿到的。

有意義的命名

爲你的類、方法、變量選擇有意義的命名，相信我，這很是重要，好的代碼應該是「自解釋」的，不只能夠提升代碼可讀性，也提升了可維護性。假如，僅僅半年後再讀本身的代碼時，看着滿篇莫名其妙的名稱，連代碼要實現什麼業務邏輯都想不起來了，能作的就只有懷疑人生了吧。

• 類的命名，應該體現出「是什麼」。好比一個提供文件讀寫功能的類，叫作 FileAccessor 就比 FileHelper 好一些，固然或許分解成 FileWriter 和 FileReader 更適合，但這要視需求而定。
• 方法的命名，應該體現出「作什麼」，描述這個方法實際作了什麼處理。好比咱們有一個根據名稱排序的方法，那麼叫作 SortByName 就比簡單的 Sort 擁有更好的可讀性。
• 變量的命名，如同類，也應該體現「是什麼」。好比一個保存文件完整路徑的變量，叫作 a 的話，簡直是反人類，叫作 f 好歹能讓我猜測這是個有關 file 的變量，若是叫作 filePath 我給90分，若是是 fileFullPath 我就給滿分。

足夠短的方法體

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

因此一旦法相一個方法體過長，就應該考慮是否須要把一個完整的邏輯段提取成一個獨立私有方法了，這樣以來，不只縮短了單個方法的長度，讓邏輯更加清晰，也能夠有效的下降風險，由於簡短代碼的邏輯複雜度勢必下降，開發人員更容易把握住。

至於「過長」是多長呢？根據我的經驗，25行就值得引發注意了，50行基本就是可忍受的上限了，除非及特殊狀況，不然儘可能不要超過這個上限。曾經維護過單個方法2000多行的人瑟瑟發抖，往事不堪回首。

無歧義的行爲

具備隱含行爲的方法，危害極大。一個方法，儘可能只作一個事情，不要作額外的事，不然很容易帶來意想不到的風險。

舉個例子，我本身寫過的一個方法。基本數據結構相似堆棧，每次從集合中取出一個對象以後，將這個對象移出集合。可是個人方法名稱是 GetXXX，結果就是發現每次取一個對象以後，集合莫名其妙（其實業務就是這樣沒錯，可是我不記得這回事兒了）地就會變短，致使後續的處理一塌糊塗。對策有兩種，一是把對象移出集合的邏輯拿到 GetXXX 的調用處來作，這樣移除動做就是顯示可見的了；或者把方法名改爲 PopXXX 或者 GetAndRemoveXXX （醜了點，但好歹看得懂），這樣以來，至少咱們的行爲與名稱是一致的，消除了歧義。

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