咱們在剛開始上課的時候介紹過一個小學四則運算自動生成程序的例子,請實現它,要求:git
代碼地址github
功能模塊名稱 | 四則運算式生成器 | ||
審查人 | 黃博 | 審查日期 | 2020/4/29 |
代碼名稱 | 四則運算.cpp | 代碼做者 | 李鑫宇 |
文件結構 | |||
重要性 | 審查項 | 結論 | |
頭文件和定義文件的名稱是否合理? | 是 | ||
頭文件和定義文件的目錄結構是否合理? | 是 | ||
版權和版本聲明是否完整? | 無 | ||
重要 | 頭文件是否使用了 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 語句時是否留下隱患? 例如跳過了某些對象的構造、變量的初始化、重要的計算等。 | 否 | |
常量 | |||
重要性 | 審查項 | 結論 | |
是否使用含義直觀的常量來表示那些將在程序中屢次出現的數字或字符串? | 是 | ||
在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)沒有正確地關閉文件嗎? | 否算法 |
本次使用VS2019單元測試工具測試編程
1.測試代碼數組
2.測試結果函數
項目 | 預計 | 實際 |
設計時間 | 1h | 2h |
編碼時間 | 4h | 6.5h |
測試時間 | 1h | 3h |
代碼行數 | 400 | 487 |
測試代碼行數 | 20 | 38 |
錯誤數量 | 5 | 7 |
錯誤修復時間 | 1h | 2h |
開發總時間 | 2d | 2d |
此次項目的駕駛員李鑫宇同窗,從任務的開始就主動承擔起編程的重任。考慮到個人編程能力很是低,他也很是照顧我,在全部關鍵的步驟上加上了很是詳細的註釋。他的編程能力思路清晰,結構嚴謹完整,對不少邊緣值都考慮周到。而且不管是在討論算法或者是代碼交付,長時間的交談並給我悉心梳理講解他的編程思路,在我不懂的地方也給我給予了指導,讓我也順利完成代碼審查工做。發現錯誤可以及時發現而且修改,他是一個很是優秀的駕駛員。工具
在本次項目中,我擔任領航員的角色,在爲期兩天的項目實現中,學到了不少的知識。首先,對於項目任務分工有了一個合理的認識,在項目分工時,合理的分工可使項目進度井井有理,不會雜亂無章。其次,對於算法的實現,由於駕駛員懂得不少算法,且編程能力很強,因此說我再他那裏學到了不少面對不一樣問題時的不一樣算法思想。接着,本次項目再一次熟悉了單元測試和代碼審覈的技能,多練習,多接觸,熟練運用一項技能,讓本身再也不成爲一條鹹魚,很重要。最後,本次時最後一次結對做業,前面四次做業已經爲接下來的團隊項目打下了堅實的基礎,我想我必定能夠在接下來的團隊做業中出一份本身的力量。爲團隊帶去盡己所能的最大貢獻。單元測試