我的博客做業 #2

代碼規範的必要性

 

關於代碼規範，存在有如下幾種偏見甚至錯誤的觀點

• 觀點一  這些規範都是官僚制度下產生的浪費你們的編程時間、影響人們開發效率, 浪費時間的東西。
• 觀點二  我是個藝術家，手藝人，我有本身的規範和原則。
• 觀點三  規範不能強求一概，應該容許不少例外。
• 觀點四  我擅長制定編碼規範，大家聽個人就行了。

　　對於觀點一， MarkCC講述了他在Google的親身經歷，他曾經看過Google的codebase，令其驚訝的是他竟然可以讀懂這些代碼，而緣由很簡單，就是Google的開發人員都遵循着相同的代碼規範，這些代碼規範可以幫助程序員們看懂任何一段遵照規範寫出來的代碼。也許有人會講，遵照這些規範會影響開發效率，但事實上開發人員是常常變更的，並且代碼一般是須要維護的，試想一下，代碼的維護人員在閱讀代碼時，大部分的時間只是爲了理清基本的語法結構，那麼開發時候遵循相同代碼規範所耗費的時間就顯得那麼微不足道了，並且代碼規範只要熟悉並加以遵循，那麼對於編碼幾乎不產生任何開發效率上的負擔。正是由於有一個統一的標準，當你在讀一段代碼時，不管它是不是你寫的，只要限定一樣的代碼結構，一樣的命名約定，你會發現根本就無需多麼費力的去讀代碼，由於你能輕易識別出代碼結構。於是咱們更加願意選擇在開發時遵循相同的代碼規範。

 

　　對於觀點二，有時程序員會對本身的代碼風格很滿意，認爲從本身的代碼中能夠體現個性以及本身的思惟過程，更是本身技能和創造力的體現，假若被迫去遵照那些蹩腳的標準，那麼無疑是對本身創造力的扼殺。然而事實上我的的思想和創造力不該體如今瑣碎的語法細節上，而應當蘊含在程序的內部。相同的代碼規範事實上更容易讓別人看到你的創造力，由於別人可以理解你在作什麼，而無需考慮瑣碎的語法細節。

 

　　對於觀點三，也許有人會認爲代碼規範不是專門針對特定項目設計的，於是很大程度來說這個代碼規範對於某個特定的項目來說不是最優的。然而，代碼規範是對語法的規定，並不最優不意味着很差，語法規範可能下降具體項目的效益，但同時也增長了大規模項目組織的效益。MarkCC介紹了他的經驗，他認爲一個項目具備特定的代碼規範這件事沒有錯，最好的作法是在一個大規模的代碼規範框架下，針對具體的項目進行擴展，使其擁有項目特定的語法風格和結構。

 

　　對於觀點四，每一個程序員都對編碼風格有強烈的自我認同。這種感受深植於每一個人的自負中，每當和同事遇到是否應該在關鍵詞周圍使用空格時，這種討論很容易升級而僵持不下。可是，靜下來想一想——這真的無所謂。不論是不是在關鍵詞周圍使用了空格，只要能達成一致，你們都能從中得到易維護和集體全部制的好處。在這種狀況中，閉着眼睛，遵循一種編碼風格就好了。

 

代碼複審（結對隊友：金哉仁）

代碼複審的評判標準參考博客：Stop More Bugs with our Code Review Checklist

複審從代碼概況，代碼安全性，代碼文檔，代碼的測試四個方面展開。

具體審覈點列舉以下：

  1.綜述：

• 代碼的有效性檢查
• 代碼模塊化檢查
• 代碼的可讀性審查
• 代碼風格檢查
• 代碼冗餘性檢查
• 代碼規範性檢查
• 代碼的可維護性檢查
• 代碼的可擴展性檢查

  2.安全性：

• 輸入的安全性檢查
• 輸出的安全性檢查
• 函數參數傳遞的安全性檢查

  3.代碼文檔：

• 關鍵代碼的意圖註釋
• 函數註釋
• 非正常狀況，邊界狀況註釋
• 第三方庫函數調用註釋
• 數據結構註釋
• 不完整代碼註釋

  4.測試：

• 代碼的可測試性
• 測試的全面性
• 測試的有效性
• 測試的可替代性（用已有API代替測試代碼）

代碼複審的結果採用思惟導圖的方式給予更加直觀的展現，以下圖：