關於「代碼規範」,「Review」和「Check list」,就我我的理解,這三者相輔相成。代碼規範是在編程時就該注意的,爲Review減輕負擔。而要進行Review,又須要一個Check list做爲支撐。在進行Review過程當中,如若發現代碼中遺漏了什麼規則,則又須要在本身的代碼規範和Check list中添加相應的項目。html
一.咱們先從「代碼規範」提及。編程
http://blog.csdn.net/kimylrong/article/details/7700311 在這篇博客中主要談到了關於JAVA編寫的三大點代碼規範,雖然略顯籠統,但就大致方向而言讓人容易掌握。模塊化
https://www.douban.com/note/82618786/ 這篇文章則更加具體的談論了JAVA編寫的代碼規範,並結合實例,一目瞭然。函數
http://wenku.baidu.com/link? url=ZEQyZjRUBBqcvJzkEalC8PdJBvW0twabaZUQPUtilnOpflFbgq31s1HmlACRFNvF5uJ_z47YNiLP2zLaKoA4elJEjJL3PfPQL2_9VHhC9Z3學習
這篇文章寫得是最爲詳細的,小到代碼縮進、對齊,大到模塊設計、輸入控制等等。優化
看了這麼多關於代碼規範的文章,說實話,本身的對於代碼規範的想法始終停留在兩點:1.格式。 2.註釋。 再仔細想一想,彷佛還有一點,「規則」,例如:命名規則、定義規則等等。但再仔細一想若是說「規則」,那「格式」與「註釋」也都應該屬於「規則」之中。故仍是具體到「格式」,「註釋」兩點。url
二. 再來講說「Review」。spa
咱們爲何要Review?Review要作些什麼?這兩點必須明確。.net
Review的目的是什麼?目的不明,結果也就無心義。我的以爲有如下幾個目的:設計
1.在項目初期就能發現代碼中的BUG,提前解決。
2.發現的問題能夠與項目組成員共享,以避免發生相似錯誤。
3.讓項目組全部人都參與Review,利於項目、工程或代碼的修改與維護。
從目的出發,Review到底要作什麼就很是清楚了。
1.根據事先定好的Check list,進行找錯,糾錯。
2.理解項目、工程或代碼的具體功能和做用。
3.在理解功能和做用的基礎上,進行鍼對性的檢查。例如:代碼完整性檢查,代碼健壯性檢查等等。
三.最後來講說Check list。
很少說,直接上文章。
http://uedc.163.com/4308.html Web交互設計優化的簡易check list
http://blog.sina.com.cn/s/blog_8c78002c0100ttmw.html 這個Check list實例,說實話,雖然樣式十分粗糙,但條理仍是很清晰的。
接下來是個人Check list。直接借鑑http://blog.jobbole.com/83595/ 此博客中的常規項。在隨後的學習生活中將繼續優化。
1.代碼可以工做麼?它有沒有實現預期的功能,邏輯是否正確等。
2.全部的代碼是否簡單易懂?
3.代碼符合你所遵循的編程規範麼?這一般包括大括號的位置,變量名和函數名,行的長度,縮進,格式和註釋。
4.是否存在多餘的或是重複的代碼?
5.代碼是否儘量的模塊化了?
6.是否有能夠被替換的全局變量?
7.是否有被註釋掉的代碼?
8.循環是否設置了長度和正確的終止條件?
9.是否有能夠被庫函數替代的代碼?
10.是否有能夠刪除的日誌或調試代碼?
若是上述內容有什麼不妥之處,請老師指出。謝謝!