1. 程式人生 > >代碼審查作業

代碼審查作業

檢查 轉換 class 棧內存 原則 所有 logs 效率 擴展

一:題目描述

(1). 首先在同學中找一個同伴,範圍不限,可以在1~5班中隨意組合,建議盡量不要找同組的成員,女同學盡量找男同學結對,但是不做強制要求;
(2). 從以往個人完成的項目中選擇一個作品,例如:以往的數據結構課程設計或者其它具有比較完整功能的小系統,代碼至少要大於100行;
(3). 將代碼上傳至個人GitHub或Coding.net系統中,並將代碼地址交給對方;
(4). 對同伴的作品進行代碼復審,並參照C/C++代碼審查表和 Java代碼審查表 這兩篇博文的內容自行設計代碼審查表並填寫內容;
(5). 將對夥伴審查的結果以表格的形式寫到自己的博客作業裏,博客中應該附有夥伴作業的GitHub或Coding.net的代碼地址;
(6). 對同伴的代碼寫一篇500字以上的評論,介紹同伴的優缺點。

二:審查代碼

結對夥伴:李娜
審查代碼地址:https://git.coding.net/LiLiLiNa/daimashencha.git

文件結構
重要性 審查項 結論
頭文件和定義文件的名稱是否合理?
頭文件和定義文件的目錄結構是否合理?
版權和版本聲明是否完整?
重要 頭文件是否使用了 ifndef/define/endif 預處理塊?
頭文件中是否只存放“聲明”而不存放“定義”
程序的版式
重要性 審查項 結論
空行是否得體?
代碼行內的空格是否得體?
長行拆分是否得體?
“{” 和 “}” 是否各占一行並且對齊於同一列?
重要 一行代碼是否只做一件事?如只定義一個變量,只寫一條語句。
重要 If、for、while、do等語句自占一行,不論執行語句多少都要加 “{}”。
重要 在定義變量(或參數)時,是否將修飾符 * 和 & 緊靠變量名?註釋是否清晰並且必要?
重要 註釋是否有錯誤或者可能導致誤解?
命名規則
重要性 審查項 結論
重要 命名規則是否與所采用的操作系統或開發工具的風格保持一致?
標識符是否直觀且可以拼讀?
標識符的長度應當符合“min-length && max-information”原則?
重要 程序中是否出現相同的局部變量和全部變量?
類名、函數名、變量和參數、常量的書寫格式是否遵循一定的規則?
靜態變量、全局變量、類的成員變量是否加前綴?
表達式與基本語句
重要性 審查項 結論
重要 如果代碼行中的運算符比較多,是否已經用括號清楚地確定表達式的操作順序?
是否編寫太復雜或者多用途的復合表達式?
重要 是否將復合表達式與“真正的數學表達式”混淆?
重要 是否用隱含錯誤的方式寫if語句? 例如
(1)將布爾變量直接與TRUE、FALSE或者1、0進行比較。
(2)將浮點變量用“==”或“!=”與任何數字比較。
(3)將指針變量用“==”或“!=”與NULL比較。
  如果循環體內存在邏輯判斷,並且循環次數很大,是否已經將邏輯判  
  斷移到循環體的外面?
重要 Case語句的結尾是否忘了加break?
重要 是否忘記寫switch的default分支?
重要 使用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。
其它常見問題
重要性 審查項 結論
重要 數據類型問題:
  (1)變量的數據類型有錯誤嗎?
  (2)存在不同數據類型的賦值嗎?
(3)存在不同數據類型的比較嗎?
重要 變量值問題:
  (1)變量的初始化或缺省值有錯誤嗎?
  (2)變量發生上溢或下溢嗎?  
  (3)變量的精度夠嗎? 不夠
重要 邏輯判斷問題:  
  (1)由於精度原因導致比較無效嗎?
  (2)表達式中的優先級有誤嗎?
  (3)邏輯判斷結果顛倒嗎?
重要 循環問題:  
  (1)循環終止條件不正確嗎?
  (2)無法正常終止(死循環)嗎?
  (3)錯誤地修改循環變量嗎?
  (4)存在誤差累積嗎?
重要 錯誤處理問題:
  (1)忘記進行錯誤處理嗎?  
  (2)錯誤處理程序塊一直沒有機會被運行?
  (3)錯誤處理程序塊本身就有毛病嗎?如報告的錯誤與實際錯誤不一致,處理方式不正確等等。  
  (4)錯誤處理程序塊是“馬後炮”嗎?如在被它被調用之前軟件已經出錯。
重要 文件I/O問題:  
  (1)對不存在的或者錯誤的文件進行操作嗎?  
  (2)文件以不正確的方式打開嗎?  
  (3)文件結束判斷不正確嗎?  
  (4)沒有正確地關閉文件嗎?  

三:總結評價

1:優點: 本程序為數據結構課設題目,代碼書寫規範整體看起來簡潔明了,在必要的地方有註釋, 我認為此程序編寫的思路邏輯結構清晰,程序易懂。

2:缺點: 可讀性,可擴展性差,代碼效率也不是很好。

3:功能: 仔細查看並運行了李娜同學的程序,她的程序模塊大概分為構建二叉樹,刪除節點,先 序中序遍歷模塊,此程序能實現二叉樹的先序中序輸出。

4:總結: 結對編程的意義就是讓大家學習小夥伴身上的長處,從而彌補自己的短處,成就更好的自己,通過這次作業,了解了我的夥伴編寫代碼的風格,也學習到了很多知識。

代碼審查作業