代碼整潔一

什麼是代碼整潔

    今天來講說「代碼整潔」，這是個永恆的話題，自從第一行代碼被寫出來後，優秀的程序員們就不停地經過各類方法、方式和工具來使本身的代碼看來整潔美觀。那爲何咱們要作代碼整潔？無論你作過幾年編程，你必定被某個傻缺的糟糕代碼絆倒過氣的找不到北；同時本身也確定寫過這種代碼把別人坑的不要不要的，讓人指着後脊樑骨暗罵一通。毛主席講過批評與自我批評，人老是在自我反省中成長，因此就先來讓咱們先看看代碼混亂主要的幾種緣由（各類案例在下一章列出）：

• l  混亂的格式排版,各類風格寫法
• l  文不對意的表達式（變量、函數、屬性等等）
• l  毫無註釋的白板代碼；
• l  麪條式函數，職責功能混雜在一塊兒；
• l  邏輯混亂的代碼；
• l  殭屍代碼，無效代碼，無數個參數的函數；
• l  ....（但願你們補充）

    若是你一直都是寫出上面所描述的混亂不堪的代碼，不只得不到同事的尊重，本身你的編碼水平也不會隨着時間推移而提高，更容易成爲N年工做經驗，混亂不堪的代碼更是將項目推向難以維護的境地。因此從我的角度上說，整潔好看的代碼不只是你技術水平體現更能讓你贏得你們的尊重；從項目角度上說，整潔優秀的代碼是產品可維護性基石，整潔有序的代碼是任何產品失控以前的第一道防線；因此優秀整潔的代碼在公在私都極爲重要，鑑於以上緣由我將代碼整潔做爲咱們分享會第一課，就是趁在座各位都還處於代碼嬰兒階段，讓你們養好習慣、打好基礎、培養好本身的代碼思想力爲大家往後成爲代碼大師打下最堅實的基礎。

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

怎麼樣作纔是代碼整潔

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

1、調整心態

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

•  「進度來不及，這個後面再優化吧，先把功能實現了」，若干年後，你會看到這段代碼依然活着，註釋依然還在；
• 「重構太麻煩了，這段代碼仍是copy一份，到我本身文件裏面去吧，重複就重複吧」，若干年後，你會看到處處都是如出一轍的代碼；
• 「這麼垃圾代碼，不是我寫的我才懶的改， 反正它運行的就好了」，總有一天你會繞不開它被它坑一次；
•  「我英文不行，變量名隨便下，aabb，文件名隨便定下」，若干年後，你會發現本身都找不到這個文件；

上述緣由，跟任何技術水平有關嗎？

   無關，所有都是心態上的問題，因此提升代碼整潔第一步就是須要提升自我責任心，不斷的心理暗示告訴本身須要對本身的代碼負責，如何寫的更好看一些，如何讓別人更容易讀懂一些，須要你有處女座般的潔癖來打造本身的代碼。

2、硬性技能

1. 有意義的命名

代碼中隨處可見命名。咱們給變量、函數、參數、類和文件命名。咱們寫代碼30%都在命名， 選個好名字要花時間，但省下來的時間比花掉的多。並且一旦發現有更好的名稱，就替換掉舊的。這麼作，讀你代碼的人（包括你本身）都會更開心？下文舊列出幾條簡單規則（本文不是討論具體代碼規範，由於有太多太多內容能夠談，因此將以概念爲主）。

1.1 名副其實的名稱

以下圖一，簡潔且格式代碼也符合.net標準。可是你能知道它作什麼嗎？

 

主要有3個問題：1、函數名不知道作什麼；2、函數參數不知道傳入什麼、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個字符原則，可是無論什麼樣顯示，咱們保持無橫向滾動條原則。