一篇好的程式碼，就如同一篇好的文章，結構合理，重點清晰，通俗易懂。積累了足夠多的編碼經驗，在完成功能之餘，自然會追求自己的程式碼更“好看”一些，接下來就談談我對於“好程式碼”的理解。

遵循規範

沒有規矩，不成方圓，遵循編碼規範，是最基本的素養。在公司，一般都會有公司規定的若干規範，在編碼時，時刻提醒要遵循這些規範，命名規則、縮排規則、換行規則……團隊不分大小，哪怕是個人獨立專案，風格統一的程式碼，是確保程式碼可讀性的前提。 如果實在不知道應該遵循怎樣的編碼規範，不妨找找看語言官方是否有推薦的規範說明，比如C#，微軟官方就提供了一套編碼規範。或者，我們可以找某個大公司的編碼規範，這些規範一般都是經過了實際專案實踐過的，可以放心使用。 養成了習慣之後，程式碼就如同學生時代寫作文那樣，無論內容好壞，首先“卷面分”是能拿到的。

有意義的命名

為你的類、方法、變數選擇有意義的命名，相信我，這非常重要，好的程式碼應該是“自解釋”的，不僅可以提高程式碼可讀性，也提高了可維護性。假如，僅僅半年後再讀自己的程式碼時，看著滿篇莫名其妙的名稱，連程式碼要實現什麼業務邏輯都想不起來了，能做的就只有懷疑人生了吧。 * 類的命名，應該體現出“是什麼”。比如一個提供檔案讀寫功能的類，叫做 FileAccessor 就比 FileHelper 好一些，當然或許分解成 FileWriter 和 FileReader 更適合，但這要視需求而定。 * 方法的命名，應該體現出“做什麼”，描述這個方法實際做了什麼處理。比如我們有一個根據名稱排序的方法，那麼叫做 SortByName 就比簡單的 Sort 擁有更好的可讀性。 * 變數的命名，如同類，也應該體現“是什麼”。比如一個儲存檔案完整路徑的變數，叫做 a 的話，簡直是反人類，叫做 f 好歹能讓我猜想這是個有關 file 的變數，如果叫做 filePath 我給90分，如果是 fileFullPath 我就給滿分。

足夠短的方法體

一旦一個方法寫得太長，勢必堆積了大量的邏輯，一旦涉及到很多巢狀或者邏輯分支，不說將來的維護難度，就是當下，很容易就把自己也繞懵了吧。 所以一旦法相一個方法體過長，就應該考慮是否需要把一個完整的邏輯段提取成一個獨立私有方法了，這樣以來，不僅縮短了單個方法的長度，讓邏輯更加清晰，也可以有效的降低風險，因為簡短程式碼的邏輯複雜度勢必降低，開發人員更容易把握住。 至於“過長”是多長呢？根據個人經驗，25行就值得引起注意了，50行基本就是可忍受的上限了，除非及特殊情況，否則儘量不要超過這個上限。曾經維護過單個方法2000多行的人瑟瑟發抖，往事不堪回首。

無歧義的行為

具有隱含行為的方法，危害極大。一個方法，儘量只做一個事情，不要做額外的事，否則很容易帶來意想不到的風險。 舉個例子，我自己寫過的一個方法。基本資料結構類似堆疊，每次從集合中取出一個物件之後，將這個物件移出集合。但是我的方法名稱是 GetXXX，結果就是發現每次取一個物件之後，集合莫名其妙（其實業務就是這樣沒錯，但是我不記得這回事兒了）地就會變短，導致後續的處理一塌糊塗。對策有兩種，一是把物件移出集合的邏輯拿到 GetXXX 的呼叫處來做，這樣移除動作就是顯示可見的了；或者把方法名改成 PopXXX 或者 GetAndRemoveXXX （醜了點，但好歹看得懂），這樣以來，至少我們的行為與名稱是一致的，消除了歧義。

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