軟體項目品質保證——編碼規範

目錄

一 編碼規範的作用

二 編碼規範不是“物神”

三 編寫編碼規範的一些建議

四 編碼規範參考

　　作為軟體開發人員，我們可以開發低等級的軟體，但不能開發低品質的軟體。所以，如何實施品質保證，是我們關注的主要問題之一，而編碼規範則是實施品質保證的第一步。

　　編碼規範已經成為一個老生常談的問題，幾乎每個項目，每家公司都會定義自己的編碼規範。但在真正實施時，卻在有意或無意地違背編碼規範。程式員，不喜歡改變自己的編程習慣。加之，管理者對品質控制不足，導致編碼規範往往形同虛設。有些人會認為：遵守編碼規範不能給項目帶來利益，也不能讓客戶看到我們為此付出的努力，其完全是團隊自發的行為，沒有必要做硬性的要求。還有些人有更好的理由：編碼規範會破壞創造性和程式品質。我認為，編碼規範，在軟體構件以及專案管理中，甚至是個人成長方面，都發揮著重要的作用，好的編碼規範是提高我們代碼品質的最有效工具之一。

一 編碼規範的作用

• 提高可讀性 “任何一個傻瓜都能寫出電腦可以理解的代碼，唯有寫出人類容易理解的代碼，才是優先的程式員。”編碼規範，協助我們寫出人類容易理解的代碼，它為我們提供了最基本的模板，良好的編碼風格，使代碼具有一定的描述性，可以通過名字來擷取一些需要IDE才能得到的提示，如可訪問性、繼承基類等。
• 統一全域，促進團隊協作 開發軟體是一個團隊活動，而不是個人的英雄主義。編碼規範，要求團隊成員遵守這一統一的全域決策，這樣成員之間可以輕鬆地閱讀對方的代碼，所有成員正以一種清晰而一致的風格進行編碼。而且，開發人員也可以集中精力關注他們真正應該關注的問題——自身代碼的商務邏輯，與需求的契合度等局部問題。
• 有助於知識傳遞，加快工作交接 風格的相似性，能讓開發人員更迅速，更容易理解一些陌生的代碼，更快速地理解別人的代碼。因為，他和你的代碼風格是一樣的，你沒有必要對他的一些個人化風格進行揣測。這樣的好處是開發人員可以很快的接手項目組其他成員的工作，快速完成工作交接。
• 減少名字增生，降低維護成本 在沒有規範的情況下，和容易為同一類型的執行個體起不同的名字。對於以後維護這些代碼程式員來說會產生疑惑。
• 強調變數之間的關係，降低缺陷引人的機會 命名可以表示一定的邏輯關係，是開發人員在使用時保持警惕，從而一定程度上減少缺陷被引人的機會。
• 提高程式員的個人能力 不可否認，每個程式員都應該養成良好的編碼習慣，而編碼規範無疑是教材之一。從一個程式員的代碼本身能看出很多東西。所以，即便是為了自身發展，作為程式員也沒有理由抵制這種規則的存在。你可能沒有認識到，我們正默默地得益於編碼規範。

二 編碼規範不是“物神”

　　在高品質的軟體中，你可以看到“架構的概念完整性”與“底層實現”之間的關係。“實現”與“架構”必須是清晰一致的，這種內在的、固有的一致性，需要編碼規範來維繫。如果沒有這種統一的約定，那麼我們做出的東西可能會充斥著各種不同的風格，顯得混亂且難以理解。團隊成員之間可能很不理解彼此之間的想法，甚至是相互抨擊。各種編碼風格上的差異會不斷擴大，而代碼品質則不斷下降。而且，團隊成員會花費時間在理解不同編程風格之間的差異，而沒有專註於真正應該解決的問題。這樣的時間消耗是難以接受的。所以，在每一個高品質代碼的背後，一定存在著一份優秀的編碼規範。

　　然而，也必須認識到編碼規範不是“物神”。編碼規範僅僅是一個全域性質的規範，它只不過是一種編程約定，不能解決更深層次的問題。就像一篇格式漂亮但內容糟糕的論文不能被發表一樣，你不能僅靠一個規範來擺脫軟體作坊。而且，在編碼規範中不宜包含那些冗長的開發技巧。我認為，對於代碼是最佳實務應該是代碼審查所要解決的，應該避免將編碼規範寫成一部關於重構的教科書。

三 編寫編碼規範的一些建議

　　以下是我對定義編碼規範的一些建議：

• 求同存異 不要妄圖改變組織的編碼習慣，除非有絕對合理的理由，否則還是以民主為主，畢竟你沒有權利要求所有人都沿用你的編碼習慣。
• 定義編碼規範越早越好 也早使用編碼規範，也早享受其帶來的好處。
• 將規範分為強制部分和推薦部分 求同存異的具體實現。將最基本的規範列放在強制部分，所有成員必須遵守；將好的但不重要的習慣列在推薦部分，開發人員可以根據自己習慣選擇是否使用。
• 編碼規範不要太長 太長的文檔沒人看，所有人都一樣，除了禮品單和工資單沒人願意看長的東西，所以編碼規範必須精鍊，最好是只有2~3頁，讓開發人員可以列印出來隨時查看。
• 必須是約定俗成的 規範必須是行業中約定俗成的，不要有什麼個人化發揮。

四 編碼規範參考

　　我本人不太推薦制定過細的編碼規範。制定編碼規範是為了增強代碼的可讀性，畢竟代碼的結構才是主要關注問題，所以我的編碼規範還是比較簡短的。裡面只是對可能會破壞編碼風格的行為進行約束，而沒有細化到“空行”甚至“空格”的層級。　

編碼規範

一 命名空間

　　<公司名稱>.(<產品名稱>|<相關技術>)[.<用途>] [.<子命名空間>]

二 代碼風格

• 花括弧“{}”不允許省略，即使只有一段代碼。
• 不允許省略存取修飾詞。
• 類型預設是密封的。
• 不允許公開欄位。
• 使用括弧“()”來強調運算子優先順序。

三 命名規範

（一） 類、結構和介面的命名

• 使用名詞或名詞短語。
• 使用Pascal方式。
• 在介面名稱前加上首碼“I”。
• 考慮在衍生類別末尾使用基類的名字。
• 如果該類僅僅為了實現某個介面，那麼請保持其與介面命名的統一。
• 如果從.NET 架構中存在的類型派生的類型，應該遵循以下規範：

基類	衍生類別
System.Attribute	要給自訂的特性添加“Attribute”尾碼
System.Delegate	要給用於事件處理的委託添加“EventHandler”尾碼  要給用於事件處理之外的那些委託添加“Callback”尾碼   不要給委託添加“Delegate”尾碼
System.EventArgs	要添加“EventArgs”尾碼
System.Exception	要添加“Exception”尾碼
IDictionary，IDictionary<T,V>	要添加“Dictionary”尾碼
IEnumerable，ICollection，IList，  IEnumerable<T>，ICollection<T>，IList<T>	添加“Collection”尾碼
System.IO.Stream	添加“Stream”尾碼
CodeAccessPermission，IPermission	添加“Permission”尾碼

（二） 成員的命名

成員	大小寫	規範
方法	Pascal（公開）、Camel（私人）	用動詞或動詞短語命名
屬性	Pascal	用名詞、名詞短語或形容詞來命名   集合屬性應該使用複數形式，而不是添加尾碼   用“Is”、“Can”、“Has”等表示布爾屬性  可以用屬性的類型名來命名屬性
事件	Pascal	使用動詞或動詞短語來命名事件  用現在時和過去時來區分前置和後置事件
欄位	Camel（私人）	要用名詞、名詞短語或形容詞來命名  不要加任何首碼

（三） 參數的命名

• Camel風格。
• 要使用left和right來命名重載的二元操作符的參數——如果參數沒有具體的含義。
• 要使用value來命名重載的一元操作符的參數——如果參數沒有具體的含義。
• 不要在參數中使用數字編號。
• 盡量使用描述性的名字命名泛型型別參數，並在前面使用“T”首碼。

（四） 常量、變數的命名

• 常量——所有單詞大寫並用“_”分隔。
• 局部變數——Camel風格。

（五） 枚舉的命名

• Pascal風格。
• 使用名詞的複數形式來命名標記枚舉。
• 不要添加“Enum”或“Flag”尾碼。
• 不要給枚舉類型值的名字加首碼。

（六） 資源的命名

• Pascal風格。
• 僅使用字母、數字和底線。
• 在命名異常訊息的資源時，資源標識符應該是異常類型名加上簡短的異常標識符。

（七） 資料庫命名

• 表——“模組名_表名”。
• 欄位——bool類型用“Is”、“Can”、“Has”等表示；日期類型命名必須包含“Date”；時間類型必須包含“Time”。
• 預存程序——使用“proc_”首碼。
• 視圖——使用“view_”首碼。
• 觸發器——使用“trig_”首碼。

（八） XML命名

　　節點名稱使用Pascal風格，屬性名稱使用Camel風格。

四 注釋

• 對介面和複雜代碼塊必須進行注釋。
• 修改代碼時保持注釋同步。
• 未完成的功能使用TODO標記。
• 修改他人代碼時要先注釋對方代碼，並寫明修改原因，不允許隨便刪除他人代碼。
• 發布前移除無用注釋。

五 異常處理

• 原則上只允許顯示拋出InvalidOperationException、ArgumentException、ArgumentNullException和ArgumentOutOfRangeException四種異常類型。
  
• 在自訂異常時，必須使用VS提供的代碼模板來建立自訂異常。