1.代碼地址

https://www.cnblogs.com/19940630naxubo/p/10768219.html

2.代碼審查表

功能模塊名稱	樹與二叉樹
審查人	那緒博	審查日期	2019.4.25
代碼名稱	樹與二叉樹	代碼作者	賈向南
文件結構
重要性? ? ??	審查項	結論
? ?? ?? ?? ?? ??	頭文件和定義文件的名稱是否合理？	合理
	頭文件和定義文件的目錄結構是否合理？	合理
	版權和版本聲明是否完整？	無版權與版權說明
重要	頭文件是否使用了 ifndef/define/endif 預處理塊?	沒有
	頭文件中是否只存放“聲明”而不存放“定義”	是
程序的版式
重要性? ? ??	審查項	結論
	空行是否得體？	否
	代碼行內的空格是否得體？	否
	長行拆分是否得體？	是
	“{” 和 “}” 是否各占一行并且對齊于同一列？	是
重要	一行代碼是否只做一件事？如只定義一個變量，只寫一條語句。	否
重要	If、for、while、do等語句自占一行，不論執行語句多少都要加 “{}”。	是
重要	在定義變量（或參數）時，是否將修飾符 * 和 ＆ 緊靠變量名？注釋是否清晰并且必要？	修飾符 * 和 ＆ 緊靠變量名，注釋清晰且必要
重要	注釋是否有錯誤或者可能導致誤解？	否
重要	類結構的public, protected, private順序是否在所有的程序中保持一致？	是
命名規則?
重要性? ? ??	審查項	結論
重要	命名規則是否與所采用的操作系統或開發工具的風格保持一致？	否
	標識符是否直觀且可以拼讀？	是
	標識符的長度應當符合“min-length && max-information”原則？	符合
重要	程序中是否出現相同的局部變量和全部變量？	否
	類名、函數名、變量和參數、常量的書寫格式是否遵循一定的規則？	是
	靜態變量、全局變量、類的成員變量是否加前綴？	否
表達式與基本語句?
重要性? ? ??	審查項	結論
重要	如果代碼行中的運算符比較多，是否已經用括號清楚地確定表達式的操作順序？	否
	是否編寫太復雜或者多用途的復合表達式？	否
重要	是否將復合表達式與“真正的數學表達式”混淆？	否
重要	是否用隱含錯誤的方式寫if語句? 例如	?
	（1）將布爾變量直接與TRUE、FALSE或者1、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語句是否正確無誤？例如字節數是否正確？類型轉換是否正 確？	未使用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.代碼缺點

無故空行

4.總結

通過這次代碼審查，我初步領悟到了結對編程的特點之代碼審查。讀別人的代碼，不僅是一個相互學習的過程，更是一個相互了解的過程。這樣可以充分了解對方的編碼習慣和思維習慣，便于提升兩人日后配合的默契。
另外，結對編程能大幅度地提高程序員的開發效率，一個人寫代碼，另一個人讀代碼，幫寫代碼的人找出潛在的錯誤。

?

轉載于:https://www.cnblogs.com/19940630naxubo/p/10768703.html

總結

以上是生活随笔為你收集整理的软件工程（2019）第四次作业-结队作业的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。