什麼是代碼整潔 今天來說說“代碼整潔”，這是個永恆的話題，自從第一行代碼被寫出來後，優秀的程式員們就不停地通過各種方法、方式和工具來使自己的代碼看來整潔美觀。那為什麼我們要做代碼整潔？不管你做過幾年編程，你一定被某個傻缺的糟糕代碼絆倒過氣的找不到北；同時自己也肯定寫過這種代碼把別人坑的不要不要的，讓 ...
什麼是代碼整潔
今天來說說“代碼整潔”，這是個永恆的話題，自從第一行代碼被寫出來後，優秀的程式員們就不停地通過各種方法、方式和工具來使自己的代碼看來整潔美觀。那為什麼我們要做代碼整潔？不管你做過幾年編程，你一定被某個傻缺的糟糕代碼絆倒過氣的找不到北；同時自己也肯定寫過這種代碼把別人坑的不要不要的，讓人指著後脊梁骨暗罵一通。毛主席講過批評與自我批評，人總是在自我檢討中成長，所以就先來讓我們先看看代碼混亂主要的幾種原因（各種案例在下一章列出）：
- l 混亂的格式排版,各種風格寫法
- l 文不對意的表達式（變數、函數、屬性等等）
- l 毫無註釋的白板代碼；
- l 麵條式函數，職責功能混雜在一起；
- l 邏輯混亂的代碼；
- l 僵屍代碼，無效代碼，無數個參數的函數；
- l ....（希望大家補充）
如果你一直都是寫出上面所描述的混亂不堪的代碼，不僅得不到同事的尊重，自己你的編碼水平也不會隨著時間推移而提升，更容易成為N年工作經驗，混亂不堪的代碼更是將項目推向難以維護的境地。所以從個人角度上說，整潔好看的代碼不僅是你技術水平體現更能讓你贏得大家的尊重；從項目角度上說，整潔優秀的代碼是產品可維護性基石，整潔有序的代碼是任何產品失控之前的第一道防線；所以優秀整潔的代碼在公在私都極為重要，鑒於以上原因我將代碼整潔作為我們分享會第一課，就是趁在座各位都還處於代碼嬰兒階段，讓大家養好習慣、打好基礎、培養好自己的代碼思想力為你們日後成為代碼大師打下最堅實的基礎。
最後，將美國童子軍的一條簡單軍規應用到我們的專業領域：“讓營地比你來的時候更乾凈。”--《代碼整潔之道》
怎麼樣做才是代碼整潔
灌了這麼多心靈雞湯，那麼我們怎麼做好代碼整潔，在我看來有兩個方面：
一、調整心態
你是否在寫代碼時，是否有下麵心理狀態：
- “進度來不及，這個後面再優化吧，先把功能實現了”，若幹年後，你會看到這段代碼依然活著，註釋依然還在；
- “重構太麻煩了，這段代碼還是copy一份，到我自己文件裡面去吧，重覆就重覆吧”，若幹年後，你會看到到處都是一模一樣的代碼；
- “這麼垃圾代碼，不是我寫的我才懶的改， 反正它運行的就行了”，總有一天你會繞不開它被它坑一次；
- “我英文不行，變數名隨便下，aabb，文件名隨便定下”，若幹年後，你會發現自己都找不到這個文件；
上述原因，跟任何技術水平有關嗎？
無關，全部都是心態上的問題，所以提高代碼整潔第一步就是需要提高自我責任心，不斷的心理暗示告訴自己需要對自己的代碼負責，如何寫的更好看一些，如何讓別人更容易讀懂一些，需要你有處女座般的潔癖來打造自己的代碼。
二、硬性技能
1. 有意義的命名
代碼中隨處可見命名。我們給變數、函數、參數、類和文件命名。我們寫代碼30%都在命名， 選個好名字要花時間，但省下來的時間比花掉的多。而且一旦發現有更好的名稱，就替換掉舊的。這麼做，讀你代碼的人（包括你自己）都會更開心？下文舊列出幾條簡單規則（本文不是討論具體代碼規範，因為有太多太多內容可以談，所以將以概念為主）。
1.1 名副其實的名稱
如下圖一，簡潔且格式代碼也符合.net標準。但是你能知道它做什麼嗎？
主要有3個問題：一、函數名不知道做什麼；二、函數參數不知道傳入什麼、三、使用字面量。歸結起來，按專業的說法：簡潔度達標，但是模糊度太高，無法見文知意。
我們先看調整後的代碼格式
這裡，我們做了幾個修改，可以很明顯看到效果：
- 變數名，不要再使用list，使用具體作用含義；
- 使用“魔法數”，不使用“字面量”，將“4”使用變數代替
1.2 一致的拼寫，避免誤導
當你在設計API,編寫業務層代碼時，沒有絕對的標準，但是請與舊代碼保持一致性。舉個例子：
正例：
GetOrganByOrgid(string orgId) GetOrganByParentId(string parentID) GetOrganByOrgEntity(Organ entity);
反例：
GetOrganData(string orgId) LoadOrganByOrgList(Organ entity) LoadOrganUseParentId(string parentID)
現代化的IDE的智能感知已經非常先進，很多程式員已經不看介面文檔，如果一致的拼寫，在IDE智能感知了，就非常方便開發人員調用；
1.3 做有意義的區分
1.3.1 不要以數字系列命名，例如a1,a2…aN。如下反例：
Public DataTable GetCostListByUserDate(DateTime date1,DateTime date2);
但是這樣，完全無法體現出來參數的作用及作者意圖，正例：
Public DataTable GetCostListByUserDate(DateTime startTime,DateTime endTime);
1.3.2 不要添加廢話修飾
不要加上,Info ,Data ,the 這些廢話定詞
例如： AccountInfo、AccountData與 Account 。其實代表一樣的含義；
再比如，
1.4 使用可搜索的名稱
同1.1中的魔法術,這點是最容易改進的，搜索“4”容易還是搜索”CHECK_FLAG”容易？
1.5 避免使用編碼，首碼
在遠古時代，因為IDE還不流行。需要在變數名前，加首碼；例如 b_ 代表byte.i_ 代碼表int類型；但是現在IDE已經非常流行了，無需再加這些首碼；
1.6 類名方法名
類名、變數名應該是名詞短語,例如： Account,Page,Customer等。
方法名，應該是動詞短語，例如：GetAccount,DownLoadPage
1.7改善措施：
l 學習英語（我老大上市公司研發部總監，依然每天朋友圈打卡學習英語，開始學習吧，沒人笑你！這是你日後職場上的最重要武器之一 ）
l 常用詞列表（會隨著部門代碼規範一起發佈）
2. 一致性的格式
2.1 團隊規則
每個coder都有自己喜歡的格式規則，但是如果在一個團隊中，就應該團隊說了算。而不是讓它顯得有一大票意見相做的個人所寫成。
我們的措施：.Net代碼規範（自定義 + StyleCop.Analyzers )
Javascript：代碼規範（需要大家群策群力）
2.2 垂直格式
向報紙學習，源文件也要像報紙文章那樣。名稱應當簡單而且一目瞭然。源文件最頂部應該給出高層次的概念和演算法。細節應該往下漸次展開，直到源文件中的最底層函數和細節。
例如：
.Net中，類中的全局變數，私有變數，常量等等，均放在類中最頂部
函數方法，public , protect private，按順序擺放。
JavaScript中，全局變數，私有變數，常量等等，均放在類中最頂部
2.3 橫向格式
我剛工作時，當時的代碼規範是橫向建議一行最多不超過80個字元。隨著近年顯示器越來越大，一行大家都預設不超過120個字元原則，但是不管什麼樣顯示，我們保持無橫向滾動條原則。
