1. 程式人生 > >作業呀作業

作業呀作業

之前 被調用 命名規則 全局 處理 順序 出錯 assert 無法

1.題目要求

本次作業要求兩個人合作完成,駕駛員和導航員角色自定,鼓勵大家在工作期間角色隨時互換,這裏會布置兩個題目,請各組成員根據自己的愛好任選一題。
題目1:
我們在剛開始上課的時候介紹過一個小學四則運算自動生成程序的例子,請實現它,要求:
能夠自動生成四則運算練習題
可以定制題目數量
用戶可以選擇運算符
用戶設置最大數(如十以內、百以內等)
用戶選擇是否有括號、是否有小數
用戶選擇輸出方式(如輸出到文件、打印機等)
最好能提供圖形用戶界面(根據自己能力選做,以完成上述功能為主)

2.任務分配

駕駛員:許晴,完成全部代碼工作,並實現了所要求的功能。
領航員:陳婷,完成代碼審查以及單元測試。

3.代碼審查表如下:

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

4.單元測試

(1)隨機生成整數函數測試

技術分享圖片

隨機生成的整數在規定範圍內

(2)運算符函數測試

技術分享圖片
當ASMD=1時,隨機生成“+”、“-”;當ASDM=2時,隨機生成“”、“/”;當ASDM=3時,隨機生成“+”,“-”、“”、“/”。

5.總結

   第一次體驗兩個人編寫一個代碼,感覺確實是不一樣的,俗話說的話“眾人拾柴火焰高”。我想,本次作業若是有我自己單獨完成,想必是非常困難的,這主要是因為自身編程的底子非常之差,所以,此次作業編寫代碼的工作完全落到了小夥伴一人的頭上。小夥伴雖然也一直在說自己編程也不行,但實際上最後還是她把程序編寫出來才讓我能夠順利進行單元測試。不得不說,感謝小夥伴的存在!通過本次的小合作,互相都認識到了對方的不足,尤其是小夥伴一直覺得是上了我的“賊船”,但現在想下去已經晚了,hiahia~~~
   最開始,小夥伴還是比較迷茫的,但她經過仔細思考之後也順利的理清思路了,理清思路之後的小夥伴簡直有如神助,刷刷就把代碼寫出來了,寫完之後修改了一些小錯誤便完成了本次的任務,大力贊美我的小夥伴——許晴。啦啦啦~~~~~~~

以下附上我兩認真工作(並不)的工作圖:
技術分享圖片

作業呀作業