目錄

一 編碼規范的作用

二 編碼規范不是“物神”

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

四 編碼規范參考

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

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

一?編碼規范的作用

• 提高可讀性?“任何一個傻瓜都能寫出計算機可以理解的代碼，唯有寫出人類容易理解的代碼，才是優先的程序員。”編碼規范，幫助我們寫出人類容易理解的代碼，它為我們提供了最基本的模板，良好的編碼風格，使代碼具有一定的描述性，可以通過名字來獲取一些需要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風格。
• 僅使用字母、數字和下劃線。
• 在命名異常消息的資源時，資源標識符應該是異常類型名加上簡短的異常標識符。

（七） 數據庫命名

• 表——“T_表名”。
• 字段——bool類型用“Is”、“Can”、“Has”等表示；日期類型命名必須包含“Date”；時間類型必須包含“Time”。
• 存儲過程——使用“proc_”前綴。
• 視圖——使用“view_”前綴。
• 觸發器——使用“trig_”前綴。

（八） XML命名

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

四 注釋

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

五 異常處理

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

轉載于:https://www.cnblogs.com/WikStone/archive/2012/03/21/2409366.html

總結

以上是生活随笔為你收集整理的软件项目质量保证——编码规范的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。