第一次結對做業代碼複審

1、代碼功能及地址

功能：足球比賽兩隊控球時間比例顯示牌

地址：https://github.com/1297340141/LED-/blob/master/1.c

2、複審結果

功能模塊名稱	足球比賽兩隊控球時間比例顯示牌
審查人	劉家興	審查日期	219.04.23
代碼名稱	1.c	代碼做者	張純鶴
文件結構
重要性	審查項	結論
	頭文件和定義文件的名稱是否合理？	不合理
	頭文件和定義文件的目錄結構是否合理？	無目錄結構
無目錄	版權和版本聲明是否完整？	無聲明
重要	頭文件是否使用了 ifndef/define/endif 預處理塊?	是
	頭文件中是否只存放「聲明」而不存放「定義」	是
程序的版式
重要性	審查項	結論
	空行是否得體？	否
	代碼行內的空格是否得體？	否
	長行拆分是否得體？	無長行
	「{」 和 「}」 是否各佔一行而且對齊於同一列？	否
重要	一行代碼是否只作一件事？如只定義一個變量，只寫一條語句。	否
重要	If、for、while、do等語句自佔一行，不論執行語句多少都要加 「{}」。	是
重要	在定義變量（或參數）時，是否將修飾符 * 和 ＆ 緊靠變量名？註釋是否清晰而且必要？	是
重要	註釋是否有錯誤或者可能致使誤解？	否
重要	類結構的public, protected, private順序是否在全部的程序中保持一致？	無類結構
命名規則
重要性	審查項	結論
重要	命名規則是否與所採用的操做系統或開發工具的風格保持一致？	否
	標識符是否直觀且能夠拼讀？	否
	標識符的長度應當符合「min-length && max-information」原則？	否
重要	程序中是否出現相同的局部變量和所有變量？	否
	類名、函數名、變量和參數、常量的書寫格式是否遵循必定的規則？	否
	靜態變量、全局變量、類的成員變量是否加前綴？	否
表達式與基本語句
重要性	審查項	結論
重要	若是代碼行中的運算符比較多，是否已經用括號清楚地肯定表達式的操做順序？	是
	是否編寫太複雜或者多用途的複合表達式？	否
重要	是否將複合表達式與「真正的數學表達式」混淆？	否
重要	是否用隱含錯誤的方式寫if語句? 例如
	（1）將布爾變量直接與TRUE、FALSE或者一、0進行比較。	無
	（2）將浮點變量用「==」或「！=」與任何數字比較。	無
	（3）將指針變量用「==」或「！=」與NULL比較。	否
	若是循環體內存在邏輯判斷，而且循環次數很大，是否已經將邏輯判 斷移到循環體的外面？	是
重要	Case語句的結尾是否忘了加break？	否
重要	是否忘記寫switch的default分支？	是
重要	使用goto 語句時是否留下隱患? 例如跳過了某些對象的構造、變量的初始化、重要的計算等。	無goto語句
常量
重要性	審查項	結論
	是否使用含義直觀的常量來表示那些將在程序中屢次出現的數字或字符串？	是
	在C++ 程序中，是否用const常量取代宏常量？	無宏常量
重要	若是某一常量與其它常量密切相關，是否在定義中包含了這種關係？	否
	是否誤解了類中的const數據成員？由於const數據成員只在某個對象	無類
	生存期內是常量，而對於整個類而言倒是可變的。	無類
函數設計
重要性	審查項	結論
	參數的書寫是否完整？不要貪圖省事只寫參數的類型而省略參數名字。	是
	參數命名、順序是否合理？	合理
	參數的個數是否太多？	否
	是否使用類型和數目不肯定的參數？	否
	是否省略了函數返回值的類型？	是
	函數名字與返回值類型在語義上是否衝突？	否
重要	是否將正常值和錯誤標誌混在一塊兒返回？正常值應當用輸出參數得到，而錯誤標誌用return語句返回。	否
重要	在函數體的「入口處」，是否用assert對參數的有效性進行檢查？	無
重要	使用濫用了assert？ 例如混淆非法狀況與錯誤狀況，後者是必然存在的而且是必定要做出處理的。	無
重要	return語句是否返回指向「棧內存」的「指針」或者「引用」？	否
	是否使用const提升函數的健壯性？const能夠強制保護函數的參數、返回值，甚至函數的定義體。「Use const whenever you need」	無
內存管理
重要性	審查項	結論
重要	用malloc或new申請內存以後，是否當即檢查指針值是否爲NULL？（防止使用指針值爲NULL的內存）	否
重要	是否忘記爲數組和動態內存賦初值？（防止將未被初始化的內存做爲右值使用）	否
重要	數組或指針的下標是否越界？	否
重要	動態內存的申請與釋放是否配對？（防止內存泄漏）	無
重要	是否有效地處理了「內存耗盡」問題？	無
重要	是否修改「指向常量的指針」的內容？	無
重要	是否出現野指針？例如（1）指針變量沒有被初始化;（2）用free或delete釋放了內存以後，忘記將指針設置爲NULL。	無
重要	是否將malloc/free 和 new/delete 混淆使用？	否
重要	malloc語句是否正確無誤？例如字節數是否正確？類型轉換是否正 確？	無
重要	在建立與釋放動態對象數組時，new/delete的語句是否正確無誤？	無
C++ 函數的高級特性
重要性	審查項	結論
	重載函數是否有二義性？	無
重要	是否混淆了成員函數的重載、覆蓋與隱藏？	無
	運算符的重載是否符合制定的編程規範？	無
	是否濫用內聯函數？例如函數體內的代碼比較長，函數體內出現循環。	無
重要	是否用內聯函數取代了宏代碼？	無
類的構造函數、析構函數和賦值函數
重要性	審查項	結論
重要	是否違背編程規範而讓C++ 編譯器自動爲類產生四個缺省的函數：
	（1）缺省的無參數構造函數；	無
	（2）缺省的拷貝構造函數；	無
	（3）缺省的析構函數；	無
	（4）缺省的賦值函數。	無
重要	構造函數中是否遺漏了某些初始化工做？	無
重要	是否正確地使用構造函數的初始化表？	無
重要	析構函數中是否遺漏了某些清除工做？	無
	是否錯寫、錯用了拷貝構造函數和賦值函數？	無
重要	賦值函數通常分四個步驟：
	（1）檢查自賦值；	無
	（2）釋放原有內存資源；	無
	（3）分配新的內存資源，並複製內容；	無
	（4）返回 *this。是否遺漏了重要步驟？	無
重要	是否正確地編寫了派生類的構造函數、析構函數、賦值函數？	無
	注意事項：
	（1）派生類不可能繼承基類的構造函數、析構函數、賦值函數。	無
	（2）派生類的構造函數應在其初始化表裏調用基類的構造函數。	無
	（3）基類與派生類的析構函數應該爲虛（即加virtual關鍵字）。	無
	（4）在編寫派生類的賦值函數時，注意不要忘記對基類的數據成員從新賦值	無
類的高級特性
重要性	審查項	結論
重要	是否違背了繼承和組合的規則？
	（1）若在邏輯上B是A的「一種」，而且A的全部功能和屬性對B而言都有意義，則容許B繼承A的功能和屬性。	無
	（2）若在邏輯上A是B的「一部分」（a part of），則不容許B從A派生，而是要用A和其它東西組合出B。	無
其它常見問題
重要性	審查項	結論
重要	數據類型問題：
	（１）變量的數據類型有錯誤嗎？	沒有
	（２）存在不一樣數據類型的賦值嗎？	不存在
	（３）存在不一樣數據類型的比較嗎？	不存在
重要	變量值問題：
	（１）變量的初始化或缺省值有錯誤嗎？	無
	（２）變量發生上溢或下溢嗎？	無
	（３）變量的精度夠嗎？	無
重要	邏輯判斷問題：
	（１）因爲精度緣由致使比較無效嗎？	無
	（２）表達式中的優先級有誤嗎？	沒有
	（３）邏輯判斷結果顛倒嗎？	否
重要	循環問題：
	（１）循環終止條件不正確嗎？	否
	（２）沒法正常終止（死循環）嗎？	無
	（３）錯誤地修改循環變量嗎？	無
	（４）存在偏差累積嗎？	無
重要	錯誤處理問題：
	（１）忘記進行錯誤處理嗎？	無
	（２）錯誤處理程序塊一直沒有機會被運行？	無
	（３）錯誤處理程序塊自己就有毛病嗎？如報告的錯誤與實際錯誤不一致，處理方式不正確等等。	無
	（４）錯誤處理程序塊是「馬後炮」嗎？如在被它被調用以前軟件已經出錯。	無
重要	文件I/O問題：
	（１）對不存在的或者錯誤的文件進行操做嗎？	無
	（２）文件以不正確的方式打開嗎？	無
	（３）文件結束判斷不正確嗎？	無
	（４）沒有正確地關閉文件嗎?	無

3、總結

1.對代碼的一些優勢感悟

• a.符合C51編程習慣，在代碼開頭從新定義聲明數據類型。

• b.思路清晰，將設計拆分開爲定時器、計算、送顯等幾部分，簡化設計，易於實現。

• c.函數功能簡單明瞭，每一個函數只幹一件事。

• d.代碼中有多個按鍵判斷，但每次按鍵判斷都加了延時消抖二次判斷，在數碼管送顯後加了消隱，很細心的設計。

2.針對複審中一些問題的意見

a.命名與註釋

在進行變量命名時應避免簡單字符以及拼音，儘可能採用符合規範的命名方式，找到本身喜歡的一種命名規範並長期堅持；在給函數和類命名時也應該明確函數的功能，並採用統一的命名規範；添加註釋時應在重要的點或者難以明瞭的地方添加，代碼更改，註釋也要同時更改，不要引發對代碼的誤解。

b.空行問題

在複審過程當中發現存在不少無心義的空行，而且無規律，嚴重下降了代碼的美觀性與可讀性。在重要的函數、方法、類、邏輯快之間添加將會提升代碼的可讀性。

c.縮進問題

代碼中存在着許多不合理的縮進，例以下圖：

而且同一行定義太多的變量，也沒有初始化，應該「一行只幹一件事」。

d.其它問題

代碼中惟一一處switch-case語句段最後並未攜帶default語句。

代碼中存在兩種花括號對齊方式，應採起一種規範，一行一個，成對出現，在同一列上對齊。

存在功能相同或相近的函數應使用一個代替，如代碼中的兩個延時函數。

以上僅僅是本人照看代碼審查表提出的一些的問題，可能不全面也可能有失偏頗，僅供參考使用。

3.複審過程對本身的啓示

以上提出來了許多問題，同時自己也不可避免的帶有這些問題，因此代碼複審的過程不只僅是查看他人，更是對本身代碼規範的一次從新審查。但願在之後的結對任務中互相幫助，共同進步。