關於「代碼規範」,「Review」和「Check list」

      關於「代碼規範」,「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.是否有能夠刪除的日誌或調試代碼?

 

      若是上述內容有什麼不妥之處,請老師指出。謝謝!

相關文章
相關標籤/搜索