.BETA工程程式碼 整理、改進目錄
學習了一些程式碼寫作規範，零零總總的總結如下:
1）在函式的開始，檢查引數的正確性，確認引數值都落在可接受的範圍裡。
2）在經歷一系列相關的表示式之後，檢查被運算元作為變數的正確性。
3）儘可能的讓函式返回一點東西。 且一定要檢查函式的返回值。
4） 在移植程式碼時，把指標演算法轉換為引用。指標會影響到正常的垃圾回收。
5） 不要直接使用文字變數，而應使用Const變數。
6） 使用錯誤日誌
7） 小心使用強制轉換
8） 不要相信任何人，即一個模組不要相信它的輸入引數是有效的。需要對外部的輸入做假設或者錯誤檢
查。
9）容易導致記憶體洩露的三種情況：
    （1）程式中的物件呼叫關係過於複雜，實在難以搞清楚某個物件究竟是否已經釋放了記憶體，此時應該
重新設計資料結構，從根本上解決物件管理的混亂局面。
　　（2）函式的return語句寫錯了，注意不要返回指向“棧記憶體”的“指標”或者“引用”，因為該內
存在函式體結束時被自動銷燬。

　　（3）使用free或delete釋放了記憶體後，沒有將指標設定為NULL。導致產生“野指標”。

個人反思總結：
    針對看到的程式碼書寫規範並反觀自己寫的程式碼，生成了以下的修改意見：
    1）程式子模組在完成了基本的功能之後，必須加上用於防禦性措施的程式碼：如，對變數、表示式、函
數進行型別和範圍的對、錯判斷和處理。
    2）為了實現最簡單方法實現功能的原則 和 實現 不要讓我動腦袋的 設計原則。在設計功能實現算
法時，必須考慮至少兩種以上的實現方法，並且比較箇中優劣，做出選擇。
    3） 寫程式碼的過程中，必須盡好、盡精的為程式碼添加註釋， 以實現“為維護者寫程式碼”的書寫程式碼
的原則。
    4）需要考慮學習 C++的記憶體使用規範，預防產生記憶體溢位的問題。
    5）書寫程式碼過程中，違背了 “開放/封閉”原則。給後來的 修改 程式合併造成了不小的工作量。
    6） 實現方法上，沒有做 萬全考量，導致 違背了 “最少意外原則”