結對編程第一次做業

審查代碼地址：https://coding.net/u/littlepudding/p/Softwarehomework_PairProgram/git?public=true

功能模塊名稱	Floyd最短路算法
審查人	呂偉華	審查日期	2018.4.5
代碼名稱	Floyd最短路算法	代碼做者	陳鑫
文件結構
重要性	審查項	結論
	頭文件和定義文件的名稱是否合理？	不合理
	頭文件和定義文件的目錄結構是否合理？	不合理
	版權和版本聲明是否完整？	不完整
重要	頭文件是否使用了 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。	否
其它常見問題
重要性	審查項	結論
重要	數據類型問題：
	（１）變量的數據類型有錯誤嗎？	否
	（２）存在不一樣數據類型的賦值嗎？	否
	（３）存在不一樣數據類型的比較嗎？	否
重要	變量值問題：
	（１）變量的初始化或缺省值有錯誤嗎？	沒有
	（２）變量發生上溢或下溢嗎？	不
	（３）變量的精度夠嗎？	夠
重要	邏輯判斷問題：
	（１）因爲精度緣由致使比較無效嗎？	否
	（２）表達式中的優先級有誤嗎？	否
	（３）邏輯判斷結果顛倒嗎？	否
重要	循環問題：
	（１）循環終止條件不正確嗎？	否
	（２）沒法正常終止（死循環）嗎？	否
	（３）錯誤地修改循環變量嗎？	否
	（４）存在偏差累積嗎？	否
重要	錯誤處理問題：
	（１）忘記進行錯誤處理嗎？	沒忘記
	（２）錯誤處理程序塊一直沒有機會被運行？	否
	（３）錯誤處理程序塊自己就有毛病嗎？如報告的錯誤與實際錯誤不一致，處理方式不正確等等。	無
	（４）錯誤處理程序塊是「馬後炮」嗎？如在被它被調用以前軟件已經出錯。	不是
重要	文件I/O問題：
	（１）對不存在的或者錯誤的文件進行操做嗎？	否
	（２）文件以不正確的方式打開嗎？	否
	（３）文件結束判斷不正確嗎？	否
	（４）沒有正確地關閉文件嗎?	否

評論

---

總的來講陳鑫同窗的代碼仍是能夠的，對於算法有充分的理解。可是仍是有問題須要改正。

優勢

1.代碼的邏輯清晰，全部的功能經過函數進行實現。代碼格式較爲規範
2.函數變量的命名清晰易懂，見名知意。
3. 對算法有必定的理解，能夠實現有關算法的功能
4. 程序有面向對象程序設計的思想

缺點

1.代碼的總體佈局和風格仍是不太好，仍是保留着刷題的編碼格式，對於內存的開闢釋放等處理的不行，雖然能夠實現代碼的功能，可是，不適合工程上的應用。
2. 部分變量的名稱不是很清晰，容易讓人產生誤解。過多的使用全局變量，在後期工程量增長時，容易產生名稱衝突
3.代碼的可擴展性比較差，只能適用於整型的數據。
4.內存的控制不是很是合理，一次性申請過多的內存空間，形成大量的浪費
5. 缺少出錯處理機制，若是程序中途出錯的話，整個程序就會崩潰掉
6.在一行中，定義裏過多的變量

---

總結

---

本次結對編程的代碼審查，可讓同伴發現咱們平時注意不到的錯誤，並及時糾正。編程的時候，咱們不只僅是要完成任務的具體要求還要考慮不少其餘的一些因素，好比：代碼的健壯性、可擴展性、容錯性、可讀性等。完成任務是代碼的一個主要功能之一，在編碼的時候，必定要注意代碼的格式規範，代碼的風格要複合符合團隊的要求。若是編碼的時候爲所欲爲，不只會給團隊的代碼審查形成麻煩，還會在後期測試、調試的時候浪費大量的時間和精力，得不償失。評價一個軟件工程師，編碼能力只是其中的一個重要方面，還有一些其餘的素質，要綜合的進行評判。好習慣必需要在平時訓練的時候進行培養，

兩人的結對編程，能夠在必定程度上提升編碼的效率和代碼的質量。畢竟旁邊有同伴的督促，能夠杜絕我的的拖延症。若是代碼的風格或者格式不對，可讓同伴及時的糾正；同時，代碼的邏輯也會比本身寫的時候更加清晰，由於不只僅要本身懂得代碼，還要讓其餘人理解個人想法。總之，經過結對編程，我對軟件開發的規範更加深刻的理解，也爲未來參加到實際的項目中，積累了大量的經驗。