好的程式碼 VS 壞的程式碼 定義(特性/標準)&比較
好的程式碼 VS 壞的程式碼 定義(特性/標準)&比較
資料來源: https://mp.weixin.qq.com/s/0W7DEvA-xXok-_srGgOKxQ
好的程式碼
01. 魯棒（Solid and Robust）
代碼不僅要被正確執行，我們還要考慮對各種錯誤情況的處理，比如各種系統調用和函數調用的異常情況，系統相關組件的異常和錯誤。
對很多產品級的程序來說，異常和錯誤處理的邏輯佔了很大比例。
02. 高效（Fast）
程序的運行應使用盡量少的資源。資源不僅僅包括CPU，還可能包括存儲、I/O等。
設計高效的程序，會運用到數據結構和算法方面的知識，同時要考慮到程序運行時的各種約束條件。
03. 簡潔（Maintainable and Simple）
代碼的邏輯要盡量簡明易懂，代碼要具有很好的可維護性。對於同樣的目標，能夠使用簡單清楚的方法達成，就不要使用複雜晦澀的方法。
“大道至簡”，能否把複雜的問題用簡單的方式實現出來，這是一種編程水平的體現。
04. 簡短（Small）
在某種意義上，代碼的複雜度和維護成本是和代碼的規模直接相關的。在實現同樣功能的時候，要盡量將代碼寫得簡短一些。
簡潔高於簡短。這裡要注意，某些人為了能把代碼寫得簡短，使用了一些晦澀難懂的描述方式，降低了代碼的可讀性。這種方式是不可取的。
05. 可測試（Testable）
代碼的正確性要通過測試來保證，尤其是在敏捷的場景下，更需要依賴可自動回歸執行的測試用例。
在代碼的設計中，要考慮如何使代碼可測、易測。一個比較好的實踐是使用TDD（Test-Driven Development，測試驅動開發）的方法，這樣在編寫測試用例的時候會很快發現代碼在可測試性方面的問題。
06. 共享（Re-Usable）
大量的程序實際上都使用了類似的框架或邏輯。由於目前開源代碼的大量普及，很多功能並不需要重複開發，只進行引用和使用即可。
在一個組織內部，應鼓勵共享和重用代碼，這樣可以有效降低代碼研發的成本，並提升代碼的質量。
實現代碼的共享，不僅需要在意識方面提升，還需要具有相關的能力（如編寫獨立、高質量的代碼庫）及相關基礎設施的支持（如代碼搜索、代碼引用機制）。
07. 可移植（Portable）
某些程序需要在多種操作系統下運行，在這種情況下，代碼的可移植性成為一種必需的能力。
要讓代碼具有可移植性，需要對所運行的各種操作系統底層有充分的理解和統一抽象。一般會使用一個適配層來屏蔽操作系統底層的差異。
一些編程語言也提供了多操作系統的可移植性，如很多基於Python語言、Java語言、Go語言編寫的程序，都可以跨平台運行。
08. 可觀測（Observable） / 可監控（Monitorable）
面對目前大量存在的在線服務（Online Service）程序，需要具備對程序的運行狀態進行細緻而持續監控的能力。
這要求在程序設計時就提供相關的機制，包括程序狀態的收集、保存和對外輸出。
09. 可運維（Operational）
可運維已經成為軟件研發活動的重要組成部分，可運維重點關注成本、效率和穩定性三個方面。
程序的可運維性和程序的設計、編寫緊密相關，如果在程序設計階段就沒有考慮可運維性，那麼程序運行的運維目標則難以達成。
10. 可擴展（Scalable and Extensible）
可擴展包含“容量可擴展”（Scalable）和“功能可擴展”（Extensible）兩方面。
在互聯網公司的系統設計中，“容量可擴展”是重要的設計目標之一。系統要盡量支持通過增加資源來實現容量的線性提高。
快速響應需求的變化，是互聯網公司的另外一個重要挑戰。可考慮使用插件式的程序設計方式，以容納未來可能新增的功能，也可考慮使用類似Protocol Buffer 這樣的工具，支持對協議新增字段。
壞的程式碼
01. 不好的函數名稱（Bad Function Name）
如do()，這樣的函數名稱沒有多少信息量；又如myFunc()，這樣的函數名稱，個人色彩過於強烈，也沒有足夠的信息量。
02. 不好的變量名稱（Bad Variable Name）
如a、b、c、i、j、k、temp，這樣的變量名稱在很多教科書中經常出現，很多人在上學期間寫代碼時也會經常這樣用。如果作為局部變量，這樣的名稱有時是可以接受的；但如果作為作用域稍微大的變量，這樣的名稱就非常不可取了。
03. 沒有註釋（No Comments）
有寫註釋習慣的軟件工程師很少，很多軟件工程師認為寫註釋是浪費時間，是“額外”的工作。但是沒有註釋的代碼，閱讀的成本會比較高。
04. 函數不是單一目的（The Function has No Single Purpose）
如LoadFromFileAndCalculate()。這個例子是我編造的，但現實中這樣的函數其實不少。很多函數在首次寫出來的時候，就很難表述清楚其用途；還有一些函數隨著功能的擴展，變得越來越龐雜，也就慢慢地說不清它的目的了。
這方面的問題可能很多人都沒有充分地認識到——非單一目的的函數難以維護，也難以復用。
05. 不好的排版（Bad Layout）
不少人認為，程序可以正常執行就行了，所以一些軟件工程師不重視對代碼的排版，認為這僅僅是一種“形式”。
沒有排好版的程序，在閱讀效率方面會帶來嚴重問題。這裡舉一個極端的例子：對於C語言來說，“;”可作為語句的分割符，而“縮進”和“換行”對於編譯器來說是無用的，所以完全可以把一段C語言程序都“壓縮”在一行內。這樣的程序是可以運行的，但是對人來說，可讀性非常差。這樣的程序肯定是我們非常不希望看到的。
06. 無法測試（None Testable）
程序的正確性要依賴測試來保證（雖然測試並不能保證程序完全無錯）。無法或不好為之編寫測試用例的程序，是很難有質量保證的。