一、代碼復審Check List

1.概要部分

• 代碼能符合需求和規格說明麽？

　　　　可以實現生成和求解的基本需求，可以處理錯誤輸出並輸出提示信息，符合規格說明

• 代碼設計是否有周全的考慮？

　　　　仍有欠缺，求解數獨輸出時可能會少輸出

• 代碼可讀性如何？

　　　　較好，但稍有欠缺，相關評論：https://github.com/Lydia-yang/2017BUAA-SoftwareEngineering/issues/1

• 代碼容易維護麽？

　　　　模塊劃分較清晰，易於維護

• 代碼的每一行都執行並檢查過了嗎？

　　　　博客中沒有覆蓋率報告，在求解數獨時讀取和輸出有bug

2.設計規範部分

• 設計是否遵從已知的設計模式或項目中常用的模式？

　　　　沒有使用設計模式

• 有沒有硬編碼或字符串/數字等存在？

　　　　有

• 代碼有沒有依賴於某一平臺，是否會影響將來的移植（如Win32到Win64）？

　　　　不依賴

• 開發者新寫的代碼能否用已有的Library/SDK/Framework中的功能實現？在本項目中是否存在類似的功能可以調用而不用全部重新實現？

　　　　沒有可以直接調用的功能

• 有沒有無用的代碼可以清除？（很多人想保留盡可能多的代碼，因為以後可能會用上，這樣導致程序文件中有很多註釋掉的代碼，這些代碼都可以刪除，因為源代碼控制已經保存了原來的老代碼。）

　　　　有少量加了註釋的代碼

3.代碼規範部分

• 修改的部分符合代碼標準和風格麽（詳細條文略）?

　　　　符合，整體風格統一

4.具體代碼部分

• 有沒有對錯誤進行處理？對於調用的外部函數，是否檢查了返回值或處理了異常？

　　　　有錯誤處理和返回值檢查

• 參數傳遞有無錯誤，字符串的長度是字節的長度還是字符（可能是單/雙字節）的長度，是以0開始計數還是以1開始計數？

　　　　無錯誤，字節的長度，從0開始。

• 邊界條件是如何處理的？Switch語句的Default是如何處理的？循環有沒有可能出現死循環？
• 有沒有使用斷言（Assert）來保證我們認為不變的條件真的滿足？

　　　　沒有

• 對資源的利用，是在哪裏申請，在哪裏釋放的？有沒有可能導致資源泄露（內存、文件、各種GUI資源、數據庫訪問的連接，等等）？有沒有可能優化？

　　　　文件在打開讀寫後就立刻關閉，數獨類在程序開始運行後申請，沒有析構

• 數據結構中是否有無用的元素？

　　　　沒有

5.效能

• 代碼的效能（Performance）如何？最壞的情況是怎樣的？

　　　　效能一般，生成100w個需要45.8s，求解5w個需要51.9s

• 代碼中，特別是循環中是否有明顯可優化的部分（C++中反復創建類，C#中string的操作是否能用StringBuilder 來優化）？

　　　　沒有

• 對於系統和網絡調用是否會超時？如何處理?

　　　　沒有使用系統和網絡調用

6.可讀性

• 代碼可讀性如何？有沒有足夠的註釋？

　　　　函數功能劃分清晰，註釋到位，但是沒有頭文件，而且有一定量註釋掉的代碼

7.可測試性

• 代碼是否需要更新或創建新的單元測試？

　　　　需要進行更多測試，原博客中並未給出單元測試結果，程序運行時也有少量問題

• 還可以有針對特定領域開發（如數據庫、網頁、多線程等）的核查表。

　　　　沒涉及到

二、設計一個代碼規範

　　工具提供的代碼規範和你個人的代碼風格有什麽不同？

• 沒有copyright信息
• 應該先加載C頭文件再加載C++頭文件
• 註釋和代碼之間至少要有2個空格，“//”和註釋內容之間要有一個空格
• 行寬應小於80個字符
• 用空格代替Tab
• else要接在“}”之後

　　工具提供的代碼規範裏有哪些部分是你之前沒有想到的？

• 沒有copyright信息
• 應該先加載C頭文件再加載C++頭文件
• else要接在“}”之後

　　為什麽要這樣規範？這樣的規範有意義嗎？

• 使用空格是為了統一代碼風格，因為Tab在不同環境下顯示的長度不同。由於舊的終端一行只能有80個字符才會有“行寬應小於80個字符”規定，雖然現在可以支持，但行寬太長也不利於閱讀。
• 為了加強可讀性和避免隱含依賴，應使用下面的順序：C標準庫、C++標準庫、其它庫的頭文件、你自己工程的頭文件。

　　在結對編程中使用的代碼規範

• 縮進使用4個空格
• 行寬不能超過1000個字符
• 只有一個語句的if等結構也要使用大括號，而且每個{和}都單獨占一行，以增強可讀性
• 一行定義一個變量，不要在一行上寫多個語句
• 類型/類/函數名的每個首字母都大寫（Pascal形式），變量的第一個單詞小寫其余首字母大寫（Camel形式）　　

個人作業Week2-代碼復審