我的做業Week2-代碼複審

1、代碼複審部分

1. 概要部分

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

代碼基本符合需求和規格說明，可是在程序中有多餘的Debug信息（sudoku.cpp中的176行）

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

有必要的錯誤處理，可是還不太徹底，有錯誤檢查沒有覆蓋的地方會引起程序異常。其餘的設計還比較周全。

代碼可讀性如何？

可讀性還能夠，變量的命名有必定的意義。可是註釋太少，而且由多個單詞組成的函數/變量名並無進行大寫區分使得並不容易快速明白函數/變量名所表達的意義。另外程序中空行過多，致使程序讀起來並不太舒服。

代碼容易維護麼？

因爲註釋比較少，可讀性並不太好，並不太容易進行維護。

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

檢查過了。

2. 設計規範部分

設計是否聽從已知的設計模式或項目中經常使用的模式？

採用的是比較普通的業務邏輯以及解體思路，並無使用特定的模式進行設計編碼。

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

有比較多的硬編碼數字。好比生成大量用的數獨模板是硬編碼的二維數組。

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

沒有平臺依賴，只要是windows均可以運行。

開發者新寫的代碼可否用已有的Library/SDK/Framework中的功能實現？在本項目中是否存在相似的功能能夠調用而不用所有從新實現？

開發者新寫的代碼並不能用已有的功能實現。

有沒有無用的代碼能夠清除？（不少人想保留儘量多的代碼，由於之後可能會用上，這樣致使程序文件中有不少註釋掉的代碼，這些代碼均可以刪除，由於源代碼控制已經保存了原來的老代碼。）

沒有無用的代碼能夠消除，可是有一些冗餘代碼能夠進行合併進行代碼簡化。

3. 代碼規範部分

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

• 函數名變量名若是由多個詞拼成，應該大寫首字母進行分割，便於快速理解含義。開發者的代碼中(例如canin函數應該是canIn更符合規範)就沒有遵循這點。

• 多餘的空行實在太多，有的連續幾行都是空行，能夠都刪減掉。

• 程序最開始的函數聲明能夠放到單獨的頭文件中，以增長程序的複用性以及可讀性。

其他代碼標準和風格都比較符合規範。

4. 具體代碼部分

github的comment地址：https://github.com/zhj123169/bin/commit/967e00868b45d023dc934a4f388462fe519073a7

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

在程序中有對輸入參數以及調用的外部函數的錯誤處理，並輸出了錯誤信息。若是要求高一點的話，對於輸入參數檢查的錯誤處理的錯誤信息輸出並不明確，之後能夠進行錯誤信息的細化方便在運行時輸出錯誤信息時能夠快速定位出錯誤發生地點。可是在參數錯誤處理上仍是有些錯誤分支並無覆蓋全（例如輸入運行指令爲 sudoku.exe -c，沒有指定生成數獨的數量，可是該狀況會認爲是正確的仍然想繼續進行參數解析，會發生不可預知的錯誤行爲）。

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

參數傳遞沒有錯誤，是以字符的長度做爲字符串的長度，從1開始取出參數進行解析。

邊界條件是如何處理的？Switch語句的Default是如何處理的？循環有沒有可能出現死循環？

數組大小基本爲99的，也有9的，因爲邊界是定死的99的，因此正常的循環訪問就能夠確保不會越界。沒有Switch語句。循環沒有可能出現死循環。

有沒有使用斷言（Assert）來保證咱們認爲不變的條件真的知足？

沒有使用斷言來保證不變的條件真的知足。

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

這個數獨軟件使用的資源爲文件資源和內存資源。文件資源方面在進行讀/寫操做時進行申請，並在使用後及時進行了釋放，沒有文件資源泄露問題。

對內存資源的利用是在函數體內申請，但沒有釋放的地方，有很是嚴重的內存泄漏問題。具體的內存泄露問題是在大量調用的transform函數體內進行了內存申請，爲每一個生成數獨申請了內存申請，可是卻將指針賦給了調用方的臨時指針，致使了嚴重的內存泄漏，使得程序後來的內存回收也比較困難（雖然程序最後也沒有釋放內存）。

內存泄露的優化有兩種，一種是在調用transform函數將原來的指針替換掉以前檢查原來的指針是否爲空，若是不爲空則釋放內存，再調用函數進行指針替換。

if(sudokuout!=NULL) free(sudokuout); // add to avoid memory leak
sudokuout = transform(oralline,oralsudoku);

或者在程序剛開始爲每一個數獨分配好內存空間，在程序最後進行統一的內存釋放，而不是在函數中分配內存空間。

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

如今的數據結構是簡單的二維表，沒有多餘無用的元素。

5. 效能

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

如今代碼的效能仍是比較差的。最壞狀況下，也就是生成100w以及求解100w個數獨時，耗時都大於420s。

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

代碼中有兩處能夠明顯優化：

• 在transform中反覆調用了malloc函數，這個會致使內存泄露的同時也是不必的在循環內的反覆申請內存空間。能夠在程序剛開始就把全部數獨的空間都申請到，最後再釋放。
• 判斷一個數可否填入空白時，用循環遍歷的方式來檢查是否有重複是比較低效的，能夠經過實時記錄某行/列/塊的某個數字是否填入（bool類型）來進行快速查重，這樣能夠每次最內層循環的至少27次比對操做就減小爲最多3次比對操做，大大提升運行速度。

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

並無系統調用和網絡調用。

6. 可讀性

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

可讀性不太好，註釋幾乎沒有，變量/函數名能夠必定程度上說明功能，但仍是不太充分，須要更多的註釋進行解釋來增長可讀性。另外過多的空行也影響了閱讀體驗。

7. 可測試性

代碼是否須要更新或建立新的單元測試？

在github上的代碼中沒有上傳單元測試，須要增長測試代碼。

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

程序沒有對特定領域的開發。

2、 設計代碼規範

工具提供的代碼規範和你我的的代碼風格有什麼不一樣？

1. 不使用using來引入某個命名空間。
2. 變量的初始化和聲明要放到一塊。    
3. 每行末尾沒有空格

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

1. 不使用using來引入某個命名空間。
2. 變量的初始化和聲明要放到一塊。    
3. 每行末尾沒有空格

爲何要這樣規範？這樣的規範有意義嗎？

這樣規範代碼能夠保證較高的代碼可讀性，並減小本身或者多人合做致使的代碼錯誤，提升了工做效率。例如上面的不使用using來引入某個命名空間能夠有效避免命名空間中的某個函數與本身的某個函數產生了命名衝突致使的異常，等等。

最後附上咱們在結對編程時使用的代碼規範：

（1）應該用4個空格代替tab
（2）{應該和代碼在同一行，而且中間有一個空格
（3）else，else if應該與if的}在同一行，且中間應當有一個空格
（4）註釋的「//」和代碼不能直接相連，中間應該有空格
（5）不可以使用using來引入某個命名空間
（6）每行的末尾不該該有空格
（7）應該有copyright
（8）代碼的中間不該該有無關注釋和無用空行
（9）函數結束後應該與下個函數間空一行
（10）過多的函數聲明能夠放到單獨的.h頭文件中
（11）變量名若是由多個單詞組成，從第二個起第一個字母應當大寫
（12）避免無用函數依舊在代碼中出現。
（13）不要使用goto語句
（14）不要將多行代碼放在同一行（好比多個變量聲明）
（15）變量的聲明必定要有初始值
（16）變量的初始化和聲明要放到一塊