功能模組名稱
檢測資料庫死鎖的等待圖法
審查人饒光宇
審查日期
2018/4/6
**名稱
檢測資料庫死鎖的等待圖法
**作者
齊鴻瑞檔案結構
重要性
審查項結論
標頭檔案和定義檔案的名稱是否合理?
是標頭檔案和定義檔案的目錄結構是否合理?
版權和版本宣告是否完整?否重要
標頭檔案是否使用了 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 語句時是否留下隱患? 例如跳過了某些物件的構造、變數的初始化、重要的計算等。
否常量
重要性
審查項結論
是否使用含義直觀的常量來表示那些將在程式中多次出現的數字或字串?
是在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)沒有正確地關閉檔案嗎?
否coding
程式是檢查輸入的有向圖是否存在死鎖,優點在於可以手動輸入也可以讀取檔案,並且對輸入做了輸入檢查,如果做了輸入檢查,那麼當使用者不小心輸入錯誤資料的時候,程式不會出錯,並且可以提示錯誤並繼續使用程式,但如果沒有輸入檢查,很有可能使用者輸入資料後直接出錯了,無法再繼續使用程式,所以做輸入檢查能很大的提公升程式使用的體驗。讓我學到了,模組化的程式設計思路,在設計功能時為使用者考慮,符合實際情況。從而設計出方便使用,人性化的程式。通過合作結對檢查**,讓我認識到了在編寫**時沒有注意到的事項,我想只有對標準有清晰的了解,才能編寫出合格的優良**。每天進步一點,就是要持之以恆。與從事其他所有的事一樣,學習絕不能三天打魚兩天曬網,更不能半途而廢。就說立定跳遠吧,在沒有掌握動作要領之前,就應該按時訓練,「學而時習之」,不斷地練習,直到最終掌握。也許那鍛鍊的過程是枯燥的,千萬別放棄。這就要有毅力和恆心。只有持之以恆,每天都進步一點,才能聚沙成塔,從不熟練到熟練,接近成功之線。
第四次作業
扎ogu 典型產品 最高傳輸速率 ieee 802.11a wi fi5 802.11a 43m 450 zyxel p334u 54mbps 1500 zyxel p335u 54mbps 1600 ieee 802.11b d link di 624 a 54mbps 215 linksys w...
第四次作業
作業題一 vs2012 rc在介面上,比beta版更容易使用,彩色的圖示和按照開發 執行 除錯等環境區分的顏色方案讓人愛不釋手。vs2012整合了asp.net mvc 4,全面支援移動和html5,wf 4.5相比wf 4,更加成熟,期待已久的狀態極工作流回來了,更棒的是,現在它的設計器已經支援c...
第四次作業
專案一求1000以內所有偶數的和 includevoid main cout sum includevoid main while i 1000 cout sum includeint main while i 1001 cout 專案3 乘法口訣表 程式設計序,輸出乙個乘法口訣表,形如 1x1 1...