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

      關於「代碼規範」，「Review」和「Check list」，就我我的理解，這三者相輔相成。代碼規範是在編程時就該注意的，爲Review減輕負擔。而要進行Review，又須要一個Check list做爲支撐。在進行Review過程當中，如若發現代碼中遺漏了什麼規則，則又須要在本身的代碼規範和Check list中添加相應的項目。

      一.咱們先從「代碼規範」提及。

      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.註釋。        再仔細想一想，彷佛還有一點，「規則」，例如：命名規則、定義規則等等。但再仔細一想若是說「規則」，那「格式」與「註釋」也都應該屬於「規則」之中。故仍是具體到「格式」，「註釋」兩點。

 

      二. 再來講說「Review」。

      咱們爲何要Review？Review要作些什麼？這兩點必須明確。

      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.是否有能夠刪除的日誌或調試代碼？

 

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