一、程式碼規範

1、簡單性原則

• What：追求簡單
  簡單性原則就是追求簡單。
  說得極端一點，就是自始至終都以最簡單的邏輯編寫程式碼，讓程式設計初學者一眼就能看懂。
  因此，在程式設計時我們要重視的是區域性的完整性，而不是複雜的整體關聯性。

• Why：Bug 喜歡出現在複雜的地方
  軟體故障常集中在某一個區域，而這些區域都有一個共同的特點，那就是複雜。編寫程式碼時如果追求簡單易懂，程式碼就很難出現問題。
  不過，簡單易懂的程式碼往往給人一種不夠專業的感覺。這也是經驗老到的程式設計師喜歡寫老練高深的程式碼的原因。所以我們要有足夠的定力來抵擋這種誘惑。

• Do：編寫自然的程式碼
  努力寫出自然的程式碼。放下高超的技巧，堅持用簡單的邏輯編寫程式碼。
  既然故障集中在程式碼複雜的區域，那我們只要讓程式碼簡單到讓故障無處可藏即可。不要盲目地讓程式碼複雜化、臃腫化，要保證程式碼簡潔。

2、同構原則

• What：力求規範
  同構原則就是力求規範。
  同等對待相同的東西，堅持不搞特殊。同等對待，舉例來說就 是同一個模組管理的數值全部採用同一單位、公有函式的引數個數統一等。

• Why：不同的東西會更顯眼
  相同的東西用相同的形式表現能夠使不同的東西更加突出。不同的 東西往往容易產生 bug。遵循同構原則能讓我們更容易嗅出程式碼的異樣， 從而找出問題所在。
  圖表和工業製品在設計上追求平衡之美，在這一點上，同構原則也 有著相似之處。統一的程式碼頗具美感，而美的東西一般更容易讓人接 受，因此統一的程式碼有較高的可讀性。

• Do：編寫符合規範的程式碼
  我們要讓程式碼符合一定的規範。不過，這會與程式設計師的自我表現欲相沖突。
  為了展現自己的實力，有些程式設計師會無視程式設計規範，編寫獨特的程式碼。可靠與簡單是程式碼不可或缺的性質，但這些程式設計師常常在無意間讓程式碼變得複雜。
  這就把智慧與個性用錯了地方。小小的自我滿足遠不及程式碼質量重要。所以在編寫程式碼時，務必剋制住自己的表現欲，以規範為先。

3、對稱原則

• What：講究形式上的對稱
  講究形式上的對稱。
  對稱原則就是講究形式上的對稱，比如有上就有下，有左就有右， 有主動就有被動。
  也就是說，我們在思考一個處理時，也要想到與之成對的處理。比 如有給標誌位置 1 的處理，就要有給標誌位置 0 的處理。

• Why：幫助讀程式碼的人推測後面的程式碼
  具有對稱性的程式碼能夠幫助讀程式碼的人推測後面的程式碼，提高其理解程式碼的速度。同時，對稱性會給程式碼帶來美感，這同樣有助於他人理解程式碼。
  此外，設計程式碼時將對稱性納入考慮的範圍能防止我們在思考問題時出現遺漏。如果說程式碼的條件分支是故障的溫床，那麼對稱性就是思考的框架，能有效阻止條件遺漏。

• Do：編寫有對稱性的程式碼
  在出現“條件”的時候，我們要注意它的“反條件”。每個控制條件都存在與之成對的反條件(與指示條件相反的條件)。要注意條件與反條件的統一，保證控制條件具有統一性。
  我們還要考慮到例外情況並極力避免其發生。例外情況的特殊性會破壞對稱性，成為故障的溫床。特殊情況過多意味著需求沒有得到整理。此時應重新審視需求，儘量從程式碼中剔除例外情況。
  命名也要講究對稱性。命名時建議使用 set/get、start/stop、begin/ end 和 push/pop 等成對的詞語。

4、層次原則

• What：講究層次
  注意事物的主從關係、前後關係和本末關係等層次關係，整理事物的關聯性。
  不同層次各司其職，同種處理不跨越多個層次，這一點非常重要。比如執行了獲取資源的處理，那麼釋放資源的處理就要在相同的層次進行。又比如互斥控制的標誌位置 1 和置 0 的處理要在同一層次進行。

• Why：層次結構有助於提高程式碼的可讀性
  有明確層次結構的程式碼能幫助讀程式碼的人抽象理解程式碼的整體結構。讀程式碼的人可以根據自身需要閱讀下一層次的程式碼，掌握更加詳細的資訊。
  這樣一來就可以提高程式碼的可讀性，幫助程式設計師表達編碼意圖，降低 bug 發生的概率。

• Do：編寫有抽象層次結構的程式碼
  在編寫程式碼時設計各部分的抽象程度，構建層次結構。保證同一個層次中的所有程式碼抽象程度相同。另外，高層次的程式碼要通過外部視角描述低層次的程式碼。這樣做能讓呼叫低層次程式碼的高層次程式碼更加簡單易懂。

5、線性原則

• What：處理流程儘量走直線
  線性原則就是讓處理流程儘量走直線。
  一個功能如果可以通過多個功能的線性結合來實現，那它的結構就會非常簡單。
  反過來，用條件分支控制程式碼、毫無章法地增加狀態數等行為會讓程式碼變得難以理解。我們要避免做出這些行為，提高程式碼的可讀性。

• Why：直線處理可提高程式碼的可讀性
  複雜的處理流程是故障的溫床。
  故障多出現在複雜的條件語句和迴圈語句中。另外，goto 等讓流程出現跳躍的語句也是故障的多發地。
  如果能讓處理由高層次流向低層次，一氣呵成，程式碼的可讀性就會大幅提高。與此同時，可維護性也將提高，新增功能等改良工作將變得更加容易。
  一般來說，自上而下的處理流程簡單明快，易於理解。我們應避開復雜反覆的處理流程。

• Do：儘量不在程式碼中使用條件分支
  儘量減少條件分支的數量，編寫能讓程式碼閱讀者線性地看完整個處理流程的程式碼。
  為此，我們需要把一些特殊的處理拿到主處理之外。保證處理的統一性，注意處理的流程。記得時不時俯瞰程式碼整體，檢查程式碼是否存在過於複雜的部分。
  另外，對於經過長期維護而變得過於複雜的部分，我們可以考慮對其進行重構。明確且可靠的設計不僅對我們自身有益，還可以給負責維護的人帶來方便。

6、清晰原則

• What：注意邏輯的清晰性
  清晰原則就是注意邏輯的清晰性。
  邏輯具有清晰性就代表邏輯能清楚證明自身的正確性。也就是說，我們編寫的程式碼要讓人一眼就能判斷出沒有問題。任何不明確的部分都 要附有說明。
  保證邏輯的清晰性要“不擇手段”。在無法用程式碼證明邏輯正確性的情況下，我們也可以通過寫註釋、附文件或畫圖等方法來證明。不過，證明邏輯的正確性是一件麻煩的事，時間一長，人們就會懶得用輔助手段去證明，轉而編寫邏輯清晰的程式碼了。

• Why：消除不確定性
  程式碼免不了被人一遍又一遍地閱讀，所以程式碼必須保持較高的可讀性。編寫程式碼時如果追求高可讀性，我們就不會採用取巧的方式編寫程式碼，編寫出的程式碼會非常自然。
  採用取巧的方式編寫的程式碼除了能讓計算機執行以外沒有任何意義。程式碼是給人看的，也是由人來修改的，所以我們必須以人為物件來編寫程式碼。
  消除程式碼的不確定性是對自己的作品負責，這麼做也可以為後續負責維護的人提供方便。

• Do：編寫邏輯清晰的程式碼
  我們要編寫邏輯清晰的程式碼。
  為此，我們應選用直觀易懂的邏輯。會給讀程式碼的人帶來疑問的部分要麼消除，要麼加以註釋。
  另外，我們應使用任何人都能立刻理解且不存在歧義的術語。要特別注意變數名等一定不能沒有意義。

7、安全原則

• What：注意安全性
  安全原則就是注意安全性，採用相對安全的方法來對具有不確定性的、模糊的部分進行設計和程式設計。
  說得具體一點，就是在編寫程式碼時刻意將不可能的條件考慮進去。比如即便某個 i f 語句一定成立，我們也要考慮 else 語句的情況；即便某個 case 語句一定成立，我們也要考慮 default 語句的情況；即便某個變數不可能為空，我們也要檢查該變數是否為 NULL。

• Why：防止故障發展成重大事故
  硬體提供的服務必須保證安全，軟體也一樣。
  硬體方面，比如取暖器，為防止傾倒起火，取暖器一般會配有傾倒自動斷電裝置。同樣，設計軟體時也需要考慮各種情況，保證軟體在各種情況下都能安全地執行。這一做法在持續運營服務和防止資料損壞等方面有著積極的意義。

• Do：編寫安全的程式碼
  選擇相對安全的方法對具有不確定性的部分進行設計。列出所有可能的執行情況，確保軟體在每種情況下都能安全執行。理解需求和功能，將各種情況正確分解到程式碼中，這樣能有效提高軟體安全執行的概率。
  為此，我們也要將不可能的條件視為考察物件，對其進行設計和程式設計。不過，為了統一標準，我們在編寫程式碼前最好規定哪些條件需要寫，哪些條件不需要寫。

二、預期計劃

三、預期目標

預期實現以下功能模組：