什麼是程式碼整潔

    今天來說說“程式碼整潔”，這是個永恆的話題，自從第一行程式碼被寫出來後，優秀的程式設計師們就不停地通過各種方法、方式和工具來使自己的程式碼看來整潔美觀。那為什麼我們要做程式碼整潔？不管你做過幾年程式設計，你一定被某個傻缺的糟糕程式碼絆倒過氣的找不到北；同時自己也肯定寫過這種程式碼把別人坑的不要不要的，讓人指著後脊樑骨暗罵一通。毛主席講過批評與自我批評，人總是在自我檢討中成長，所以就先來讓我們先看看程式碼混亂主要的幾種原因（各種案例在下一章列出）：

• l  混亂的格式排版,各種風格寫法
• l  文不對意的表示式（變數、函式、屬性等等）
• l  毫無註釋的白板程式碼；
• l  麵條式函式，職責功能混雜在一起；
• l  邏輯混亂的程式碼；
• l  殭屍程式碼，無效程式碼，無數個引數的函式；
• l  ....（希望大家補充）

    如果你一直都是寫出上面所描述的混亂不堪的程式碼，不僅得不到同事的尊重，自己你的編碼水平也不會隨著時間推移而提升，更容易成為N年工作經驗，混亂不堪的程式碼更是將專案推向難以維護的境地。所以從個人角度上說，整潔好看的程式碼不僅是你技術水平體現更能讓你贏得大家的尊重；從專案角度上說，整潔優秀的程式碼是產品可維護性基石，整潔有序的程式碼是任何產品失控之前的第一道防線；所以優秀整潔的程式碼在公在私都極為重要，鑑於以上原因我將程式碼整潔作為我們分享會第一課，就是趁在座各位都還處於程式碼嬰兒階段，讓大家養好習慣、打好基礎、培養好自己的程式碼思想力為你們日後成為程式碼大師打下最堅實的基礎。

最後，將美國童子軍的一條簡單軍規應用到我們的專業領域：“讓營地比你來的時候更乾淨。”--《程式碼整潔之道》

怎麼樣做才是程式碼整潔

灌了這麼多心靈雞湯，那麼我們怎麼做好程式碼整潔，在我看來有兩個方面：

一、調整心態

你是否在寫程式碼時，是否有下面心理狀態：

•  “進度來不及，這個後面再優化吧，先把功能實現了”，若干年後，你會看到這段程式碼依然活著，註釋依然還在；
• “重構太麻煩了，這段程式碼還是copy一份，到我自己檔案裡面去吧，重複就重複吧”，若干年後，你會看到到處都是一模一樣的程式碼；
• “這麼垃圾程式碼，不是我寫的我才懶的改， 反正它執行的就行了”，總有一天你會繞不開它被它坑一次；
•  “我英文不行，變數名隨便下，aabb，檔名隨便定下”，若干年後，你會發現自己都找不到這個檔案；

上述原因，跟任何技術水平有關嗎？

   無關，全部都是心態上的問題，所以提高程式碼整潔第一步就是需要提高自我責任心，不斷的心理暗示告訴自己需要對自己的程式碼負責，如何寫的更好看一些，如何讓別人更容易讀懂一些，需要你有處女座般的潔癖來打造自己的程式碼。

二、硬性技能

1. 有意義的命名

程式碼中隨處可見命名。我們給變數、函式、引數、類和檔案命名。我們寫程式碼30%都在命名， 選個好名字要花時間，但省下來的時間比花掉的多。而且一旦發現有更好的名稱，就替換掉舊的。這麼做，讀你程式碼的人（包括你自己）都會更開心？下文舊列出幾條簡單規則（本文不是討論具體程式碼規範，因為有太多太多內容可以談，所以將以概念為主）。

1.1 名副其實的名稱

如下圖一，簡潔且格式程式碼也符合.net標準。但是你能知道它做什麼嗎？

主要有3個問題：一、函式名不知道做什麼；二、函式引數不知道傳入什麼、三、使用字面量。歸結起來，按專業的說法：簡潔度達標，但是模糊度太高，無法見文知意。

我們先看調整後的程式碼格式

    這裡，我們做了幾個修改，可以很明顯看到效果：

1. 變數名，不要再使用list，使用具體作用含義；
2. 使用“魔法數”，不使用“字面量”，將“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個字元原則，但是不管什麼樣顯示，我們保持無橫向滾動條原則。