王垠《編程的智慧》總結

根據王垠大牛的《編程的智慧》文章總結，我看的原文地址是https://kb.cnblogs.com/page/549080/

當經歷有一些年頭的編程後，纔會更爲共鳴，真正厲害的劍法，老是簡單到無以復加的。

1、提煉代碼是編程的修行

1. 反覆回頭推敲代碼（優化、精簡）是提升編程水平最高效的方法，這和寫文章提煉是一樣道理

2. 衡量程序員水平不是看他寫了多少代碼，而是看他刪除了多少代碼

3. 如反覆提煉代碼再也不有進展，暫時放下，幾個星期或幾個月後再回頭看，也許有面目一新的靈感（也即溫故而知新）

4. 反覆回頭提煉能積累起靈感和智慧，從而在遇到新問題時直接朝正確或接近正確的方向前進

5. 優雅代碼的形狀是枝丫分明的樹狀結構（tree）

   2、 如何寫模塊化代碼

6. 模塊化不是文件或文本意義上的，而是邏輯上的

7. 一個模塊化就像電路芯片同樣，有定義良好的有輸入輸出，函數就是這個電路片

8. 避免寫太長的函數，不超過40行最好，超出就拆分掉

9. 常重複的哪怕只有二行也宜提取出去製造小的工具函數，它們能大大簡化主函數邏輯（無散亂代碼亂眼，每句都有意義能讓函數更爲清晰）

10. 不要用宏來代替小函數，用宏是過期的觀念，會使程序難以理解、調試，容易出錯

11. 每一個函數只作一件簡單的事情，不要搞通用函數

12. 避免使用全局變量和類成員傳遞信息

13. 真正優雅可讀的代碼，是幾乎不須要註釋的

14. 不需註釋，讓代碼本身解釋本身

15. 用程序語言的簡潔嚴謹自己來表達它到底在幹什麼

16. 使用能切實描述它們邏輯的函數和變量名字
    如put (elephant1, fridge2); 把大象放進冰箱。

17. 局部變量應該儘可能接近使用它的地方

18. 局部變量名字應該簡短

19. 不要重用局部變量，局部變量應在有效域或可見範圍內意義惟一

20. 把複雜的邏輯提取出去作成幫助函數，則原來的地方就可以使用一個有意義的函數代替註釋

21. 把複雜的表達式提取出去作成中間變量

22. 按一句一表達的邏輯換行

    3、寫簡單代碼

23. 避免使用自增減表達式（i++，++i，i–，–i）

24. 永遠不要省略花括號（一塊一做用域）

25. 合理使用括號，不要盲目依賴操做符優先級

26. 避免使用continue和break，如出現，努力改寫循環

27. 寫直觀的代碼，如把

    if (action1() || action2() && action3()) { ... }

    寫爲：

    if (!action1()) { 
      if (action2()) { 
        action3(); 
      } 
    }
    

    　　

28. 寫無懈可擊的代碼，程序流的全部分支應到位，避免出現疏漏（例如if..else）

29. if..else若是省略分支，每次讀這段代碼，你都不能確信它照顧了全部的狀況，又得從新推理一遍，帶來沉重的頭腦開銷

    4、正確處理錯誤

30. try…catch裏面，應該包含儘可能少的代碼

31. 在異常出現的當時就做出處理，不要丟回給調用者

32. 不該該使用 Exception這麼寬泛的類型。你應該正好 catch 可能發生的那種異常A

    5、正確處理null指針

33. 儘可能不要產生null指針（不要用null初始變量、函數不要返回null）

34. 不要把 null 放進「容器數據結構」裏面

35. 函數調用者：明確理解 null 所表示的意義，儘早檢查和處理 null 返回值，減小它的傳播

36. 函數做者：明確聲明不接受 null 參數，當參數是 null 時當即崩潰

    6、防止過分工程

37. 當過分思考「未來」是過分工程即將出現的重要信號

38. 過分關心併爲「代碼重用」設計也是過分工程，拖垮進度

39. 過分關心「測試」也會引發過分工程
    根據這些，做者給出了防止過分工程的原則以下：

• 1.先把眼前的問題解決掉，解決好，再考慮未來的擴展問題。

• 2.先寫出可用的代碼，反覆推敲，再考慮是否須要重用的問題。

• 3.先寫出可用，簡單，明顯沒有 bug 的代碼，再考慮測試的問題。