《編程匠藝》之代碼的表面

第一部分: 處理代碼的細節(代碼的表面)

處理代碼的細節,主要分爲以下的幾個方向,check:

1. 善於防守, 考慮代碼的健壯性.
2. 好的樣式.精心佈局.
3. 爲文件和函數以及各部分起個好名字.
4. 良好的註釋.
5. 錯誤處理,處理好可能會出現的錯誤.保證不崩潰.
6. 邏輯清晰,可理解.

1. 防護性

防護性的誘因:

1. 惡意用戶
2. 客戶端錯誤的使用
3. 運行環境不完整
4. 外部運行庫問題

若是可使用函數局部變量,就不要使用全局變量.若是能使用循環體內的變量,就不使用函數級變量.

防護要義:

1. 使用合適的風格和規範.
2. 邏輯清晰, 而不是簡潔.
3. 開啓合適的警告級別.
4. 使用靜態lint檢查工具.
5. 檢查返回值,適當的處理之.
6. 合理使用日誌以及級別.
7. 謹慎的進行類型轉換.
8. 適當的約束,檢查數組邊界, 指針

Q & A:

1. 爲每一個修復的bug最好都作一個單元測試.

2. 精心佈局

1. 調整好風格, 調整好tab寬度等.

3. 起個好名字

須要命名的對象有:

1. 變量
2. 函數
3. 類型
4. 包名字
5. 宏
6. 文件名

• 爲名字起好名字的關鍵是理解所命名的對象.
• 進行命名時,重點放在清晰而非簡潔上.可是若是是做爲循環計數器,那麼可使用短的變量.
• 命名函數時,由於函數是方法, 那麼最好是一個動詞開頭, 表名某種邏輯功能.
• 宏命名時,全大寫, 並以項目名爲前綴.
• 文件名儘量描述文件功能;能夠拆分文件中的多個邏輯.
• 命名要保持一致.
• 起名字時,要肯定其範圍, 容易有明確的描述.

4. 編寫自說明的代碼技巧

1. 不要編寫須要外部文檔支持的代碼, 由於對於一個大型的項目, 維護文檔自己就是一個很大的挑戰, 尤爲是代碼在不斷的迭代中.
2. 那麼使用註釋是一個好主意麼?No, 散落在各處的註釋, 並非好的自說明.
3. 好的代碼如同一本組織良好的書.
   • 前言對應文件的代碼註釋頭, 說明文件的內容,做用,屬於的項目等.
   • 目錄對應文件中的函數,類,變量的列表(現代軟件可使用ide)
   • 部分對應一個代碼部分.不推薦單文件過大, 能夠把幾個源文件打包成一個"部分",表明一個大的邏輯部分.
   • 章對應某一個源文件, 他是功能獨立完整的邏輯函數集合.
   • 段落對應每一個函數的代碼組織,如變量在最前面等.
   • 語句對應每條語句.
4. 使用好的樣式編寫簡單的代碼
   • 讓正常的流程貫穿代碼,處理錯誤或者正確的分支老是放在前面.
   • 避免過多的嵌套.
   • 謹慎的優化代碼,若是不易理解, 要清晰的註釋.
5. 選擇有意義的名稱
   • 全部的變量, 函數, 文件名, 類型, 都應該有準確的含義.
6. 分解爲原子函數
   • 一個函數,一種操做.觀察函數名字就能知道函數功能.
   • 保持簡短.
7. 使用合適的類型
   • 如變量不包含負值,那麼就直接使用uint
   • 若是變量不可修改, 那麼就用const修飾
8. 突出重要的代碼
   • 隱藏不重要的信息和代碼
   • 限制嵌套的條件語句的數量.避免重要的處理條件被嵌套隱藏.
9. 分組相關信息
   • 經過使用語言的機制,將相關信息分組, 在go中, 就是包.在c中, 就是文件.
10. 恰當的處理錯誤
    • 不要返回無心義的錯誤, 每一層處理本身的錯誤.如在訪問磁盤的代碼中出現錯誤,那麼這一層就處理磁盤錯誤,而後向上拋出錯誤, 上層可能處理的是打開文件錯誤等.
11. 對於一個自描述的代碼,還須要什麼什麼文檔?
    • 須要一個描述整個系統和做用的文檔
    • 系統的結構概要文檔和設計文檔
    • 測試規範

5. 編寫合適的註釋

1. 只須要編寫夠用的註釋,過猶不及.
2. 對於複雜的地方, 要解釋爲何這麼作更重要, 至於作了什麼, 若是是自說明的代碼, 已經交代的很清楚了.
3. 不要文檔化差勁的代碼, 重寫它.可使用單元測試來保證重寫後不會破壞功能.
4. 註釋應該活在如今, 不要描述已經改變的事情, 也不要講述某個事物過去是作什麼的.
5. 當你修改代碼時,維護周邊的全部註釋.

6. 處理出現的錯誤

1. 錯誤產生的緣由總結一下歸爲三種:
   • 用戶錯誤,用戶錯誤的輸入或者操做等
   • 程序員錯誤
   • 意外狀況
2. 爲了控制代碼的錯誤,咱們須要作到:
   • 當出現錯誤時提出錯誤
   • 檢測全部可能的錯誤報告
   • 恰當的處理錯誤
   • 傳播咱們不能處理的錯誤
3. 錯誤報告機制
   • 不報告,好比出現錯誤, 就停止,可是不是好主意.
   • 使用返回值
   • 使用錯誤狀態變量,如c語言的errno, 不要用這種方式
   • 異常
   • 使用信號
4. 處理錯誤
   • 什麼時候處理錯誤
   • 儘量早的處理(儘量晚的處理) ,沒有好壞, 折中
5. 錯誤後的清理的方法