10 Tips for Writing Better Code （閱讀理解）
出發點
http://www.tuicool.com/articles/A7VrE33
閱讀中文版本《編寫質優代碼的十個技巧》，對於我編碼十年的經驗，也有相同感受，
太多的坑趟過，太多的經歷走過，對良好編碼的技巧，只能說更加心有靈犀。
下面從英文原版閱讀，結合自己的理解，嘗試註解下作者的觀點。
註解 -- 原文見下網址
https://cdiggins.github.io/blog/programming-tips.html
10 Tips for Writing Better Code
註：翻譯成編寫更好代碼的十個技巧，不如翻譯成質量優良代碼的十個技巧，更好合適。
30+ years experience trying to write better software distilled down into 10 best practices.
註：30多年努力編寫質量優良軟件的經驗， 被提煉為10個最佳實踐。為工匠精神點贊， 中國的程序員不用擔心30歲以後要失業，看看人家幹了30年了。
1. Follow the Single Responsibility Principle
Functions are the single most important form of abstraction in a programmer‘s arsenal. The more they can be reused the less code you have to write, and the more reliable they become. Smaller functions that follow the Single responsibility principle are more likely to be resued
註：一件函數只做一件事情， 此精神類似unix設計哲學， 極簡而奢。 函數是程序的細胞， 每一個細胞是可復用的， 健康度良好的， 則使用函數組織起來軟件，必然是健壯的， 並且更好維護， 更快地組建新的軟件。
2. Minimize Shared State
You should minimize implicit shared state between functions, whether it is a file scoped variable or object‘s member fields, in favor of explicitly required values as arguments. Code becomes a lot easier to understand and reuse when it explicit what that function requires to produce the desired results.
A corrollary to this is that you should prefer static stateless variables to member variables on an object.
註： 共享狀態本身就不應該存在， 不應該在不同的函數之前共享同一個變量， 特別是變量是全局變量，造成程序邏輯不清晰， 容易走到異常情況。
如果必須要有共享狀態， 則必須使用函數入參的形式， 顯示聲明，函數依賴的變量， 不要去引用全局變量。
這種思想， 是函數式編程的思想， 對於純函數， 即給定函數的輸入， 函數的輸出在任何情況下都是固定的， 可預期，不用擔心依賴全局變量，產生的不可控制性。
函數式編程，典型代表語言有 haskell， js中有facebook出品的 immutablejs（https://github.com/facebook/immutable-js）， 也是為了達到這種效果。
3. Localize Side Effects
Ideally side-effects (e.g. printing to console, logging, changing global state, file-system manipulations, etc.) should be placed in separate modules, and not scattered throughout the code. Often side-effects in functions are violating the single responsibility principle.
註： 局部化副作用， 對於存在副作用， 例如函數的執行， 改變的全局變量， 則盡量將副作用局部化， 例如局部化到模塊， 不要讓副作用散落在程序的任何地方。
即減少副作用的影響範圍。
4. Prefer Immutable Objects
If an object‘s state is set once in its constructor and never changed again it become much easier to debug since it remains valid once it is constructed correctly. This is one of the easiest ways to reduce complexity in a software project.
註： 優選不可變對象。 對象的屬性在程序運行過程中， 不被改變， 更加易於調試。 例如 array.map 接口設計， array.map（v=v+1）， 此操作不改變array對象本身， map函數會產生一個新的 array，並返回。
5. Interfaces over Classes
Functions that accept an interface (or a template argument or concept in the case of C++) are more reusable than functions that operate on a class.
註： 函數接受接口， 更加具有復用性， 相比較函數接受 類。
面向接口的編程， 比面向類的編程， 更加具有靈活性。
一： 如果函數依賴與類， 則函數只能服務於此類， 和此類的子類。 如果依賴接口， 則函數可以服務於任何實現了此接口的任何對象。
二：如果函數依賴類， 函數依賴的對象變大， 實際其只需要依賴 接口， 容易在函數中 產生副作用， 調用了類的其它非接口的公共函數和屬性。
6. Apply Good Principles to Modules
Look for opportunties to break up a software project into smaller modules (e.g. libraries and applications) to encourage module level reuse. Some key principles to follow for modules are:
- Minmize dependencies
- Each project should have a single well defined responsibility
- Don‘t repeat yourself
You should strive to keep your project small and well-defined.
註： 尋找機會分解軟件項目為更小的模塊， 例如庫和應用， 這是為了鼓勵 模塊級別重用。一些關鍵的原則：1、 極小化模塊之間的依賴， 2、每個模塊有一個單一的定義良好的職責， 3、不要重復。
軟件開發， 一個關鍵的環節就是設計， 設計就是要把整個系統 拆分為不同的子模塊， 這樣減少軟件開發的復雜度，即使的復雜度處於可控範圍內。 模塊與模塊之間的鏈接盡量小，並且明確， 符合 “高內聚、低耦合”原則。
7. Avoid Inheritance
In object-oriented programming, inheritance, especially with virtual functions tends to be a dead-end in terms of reusability. I have had very little success writing or working with libraries that encourage overriding classes.
註： 避免繼承。 繼承減少的服用性， 繼承之後， 必然有一些函數或者屬性， 是需要覆蓋父親類的， 或者新增父親類沒有的函數和屬性。
如果一個對象， 其劃分的比較合理， 職責比較單一， 則對象的所有屬性和函數是一套整體的內容， 子類的函數覆蓋， 或者新增， 很容易就割裂了對象的整體性，
一部分邏輯在父親， 一部分邏輯在兒子， 實際上造成了邏輯的低耦合。
8. Test as you Design and Develop
I am not a hard-core advocate of test-driven development but writing tests as you go leads to code that naturally follows many of the guidelines. It also helps reveal n error earlier. Avoid writing useless tests though, good coding practices mean that higher level tests (e.g. integration tests or feature tests over unit tests) are much more effective at revealing defects.
註：當你開發過程中， 寫測試， 有助於發現低水平的缺陷， 進而促進集成測試和功能測試， 更加有效地發現缺陷。
9. Prefer Standard Libraries to Hand-Rolled Ones
I can‘t tell you how often I have seen a better version of std::vector or std::string, but it almost invariably a waste of time and effort. Apart from the obvious fact that you are introducing a new place for bugs (see Tip #10), other programmers are far less likely to reuse your code as opposed to something that is widely understood, supported, and tested.
註： 優選標準庫， 不要手工制造了。 自己造輪子， 則多出一個產生bug的口子， 使用標準庫， 則不容易出現bug， 因為標準庫已經被官方測試發布過， 更加質量優良， 且有bug， 也很快被修復。自己造， 一則浪費時間， 二則容易引入bug。
10. Avoid Writing New Code
This is the most important tip that every programmer should follow: the best code is the code that isn‘t written. The more lines of code you have, the more defects you will have, and the harder it is to find and fix bugs.
Before writing a line of code ask yourself, is there a tool, function, or library that already does what you need? Do you really need that function as opposed to calling another one that already exists?
註： 最好的代碼就是自己不寫代碼。 以無招勝有招， 達到武學最高境界。 不說啥了，盡量不要自己造輪子， 使用別人造的輪子。 如果真想造， 就參加開源項目， 為開源事業貢獻力量。
Final Words
I have found that programming is a skill very similar to learning an art form or a sport, you get better at it through mindful practice, and by learning from others. Continuously working to improve the quality of the code you produce will help you become a more effective programmer.
持續改進你的代碼， 會幫助你稱為一個更加高效的程序員。
致敬30年的老兵！！
10 Tips for Writing Better Code （閱讀理解）