根據王垠大牛的《編程的智慧》文章總結，我看的原文地址是https://kb.cnblogs.com/page/549080/
當經歷有一些年頭的編程后，才會更為共鳴，真正厲害的劍法，總是簡單到無以復加的。
一、提煉代碼是編程的修行
-
反復回頭推敲代碼（優化、精簡）是提高編程水平最高效的方法，這和寫文章提煉是同樣道理
-
衡量程序員水平不是看他寫了多少代碼，而是看他刪除了多少代碼
-
如反復提煉代碼不再有進展，暫時放下，幾個星期或幾個月后再回頭看，也許有煥然一新的靈感（也即溫故而知新）
-
反復回頭提煉能積累起靈感和智慧，從而在遇到新問題時直接朝正確或接近正確的方向前進
-
優雅代碼的形狀是枝丫分明的樹狀結構（tree）
二、 如何寫模塊化代碼
-
模塊化不是文件或文本意義上的，而是邏輯上的
-
一個模塊化就像電路芯片一樣，有定義良好的有輸入輸出，函數就是這個電路片
-
避免寫太長的函數，不超過40行最好，超出就拆分掉
-
常重復的哪怕只有二行也宜提取出去制造小的工具函數，它們能大大簡化主函數邏輯（無散亂代碼亂眼，每句都有意義能讓函數更為清晰）
-
不要用宏來代替小函數，用宏是過時的觀念，會使程序難以理解、調試，容易出錯
-
每個函數只做一件簡單的事情，不要搞通用函數
-
避免使用全局變量和類成員傳遞信息
-
真正優雅可讀的代碼，是幾乎不需要注釋的
-
不需注釋，讓代碼自己解釋自己
-
用程序語言的簡潔嚴謹本身來表達它到底在干什么
-
使用能切實描述它們邏輯的函數和變量名字
如put (elephant1, fridge2); 把大象放進冰箱。 -
局部變量應該盡量接近使用它的地方
-
局部變量名字應該簡短
-
不要重用局部變量，局部變量應在有效域或可見范圍內意義唯一
-
把復雜的邏輯提取出去做成幫助函數，則原來的地方就可使用一個有意義的函數代替注釋
-
把復雜的表達式提取出去做成中間變量
-
按一句一表達的邏輯換行
三、寫簡單代碼
-
避免使用自增減表達式（i++，++i，i–，–i）
-
永遠不要省略花括號（一塊一作用域）
-
合理使用括號，不要盲目依賴操作符優先級
-
避免使用continue和break，如出現，努力改寫循環
-
寫直觀的代碼，如把
if (action1() || action2() && action3()) { ... }寫為：
if (!action1()) { if (action2()) { action3(); } } -
寫無懈可擊的代碼，程序流的所有分支應到位，避免出現疏漏（例如if..else）
-
if..else如果省略分支，每次讀這段代碼，你都不能確信它照顧了所有的情況，又得重新推理一遍，帶來沉重的頭腦開銷
四、正確處理錯誤
-
try…catch里面，應該包含盡量少的代碼
-
在異常出現的當時就作出處理，不要丟回給調用者
-
不應該使用 Exception這么寬泛的類型。你應該正好 catch 可能發生的那種異常A
五、正確處理null指針
-
盡量不要產生null指針（不要用null初始變量、函數不要返回null）
-
不要把 null 放進“容器數據結構”里面
-
函數調用者：明確理解 null 所表示的意義，盡早檢查和處理 null 返回值，減少它的傳播
-
函數作者：明確聲明不接受 null 參數，當參數是 null 時立即崩潰
六、防止過度工程
-
當過度思考“將來”是過度工程即將出現的重要信號
-
過度關心並為“代碼重用”設計也是過度工程，拖垮進度
-
過度關心“測試”也會引起過度工程
根據這些，作者給出了防止過度工程的原則如下：
-
1.先把眼前的問題解決掉，解決好，再考慮將來的擴展問題。
-
2.先寫出可用的代碼，反復推敲，再考慮是否需要重用的問題。
-
3.先寫出可用，簡單，明顯沒有 bug 的代碼，再考慮測試的問題。