《.NET 規範》第 3 章 命名規範

標籤：組織架構   tle   別名   rgs   通用   after   end   edit   協助   

《.NET 規範》第 3 章 命名規範3.1 大小寫約定

　　要把 PascalCasing 用於由多個單詞構成的命名空間、類型以及成員的名字。

　　要把 camelCasing 用於參數的名字。

　　要把兩個字母的首字母縮寫詞全部大寫，除非它是 camelCasing 風格的參數名的第一個單詞。

　　要把由三個或三個以上字母組成的首字母縮寫詞的第一個字母大寫。只有第一個字母大寫，除非首字母縮寫詞是 camelCasing 風格的標識符的第一個單詞。

　　不要把 camelCasing 風格的標識符頭部的任何首字母縮寫詞的任何字母大寫，無論首字母縮寫詞的長度是多少。

　　不要把所謂閉合形式的複合詞中每個單詞的首字母大寫。

　　不要以為所有的程式設計語言都是區分大小寫，實際情況並非如此。不應該僅僅通過大小寫來區分名字。

　　

3.2 通用命名慣例

　　要為標識符選擇易於閱讀的名字。

　　要更看重可讀性，而不是更看重簡潔性。

　　不要使用底線、連字號以及其他任何既非字母數位字元。

　　不要使用匈牙利命名法。

　　避免使用與廣泛使用的程式設計語言的關鍵字有衝突的標識符。

　　不要使用縮寫詞和縮減詞作為標識符名字的組成部分。例如，要使用 GetWindow，而不用 GetWin。

　　不要使用未被廣泛接受的首字母縮寫詞，即使是被廣泛接受的首字元縮寫詞，也只應該在必需的時候才使用。

　　要給類型名使用語義上有意義的名字，而不要使用語言特有的關鍵字。

　　要使用 CLR 的通用類型名，而不是使用語言特有的別名 - 如果除了類型之外，標識符沒有其他的語義。

　　要使用常見的名字，比如 value 或 item，而不要重複類型的名字 - 如果除了類型之外，標識符沒有其他的語義，而且參數的類型無關緊要。

　　要在建立已有 API 的新版本時使用與舊 API 相似的名字。

　　要優先使用尾碼而不是首碼來表示已有 API 的新版本。

　　考慮使用全新但有意義的標識符，而不是簡單地給已有標識符添加尾碼或首碼。

　　要使用數字尾碼來表示已有 API 的新版本 - 如果已有 API 的名字是唯一有意義的名字（也就是說，它是一個工業標準），不適宜添加尾碼（或改名）。

　　不要在標識符中使用“Ex”（或類似的）尾碼來區分相同 API 的不同版本。

　　要引入對 64 位元整數（long）而非 32 位整數進行操作的新版 APi 時使用“64”尾碼。只有當已經存在 32 位的 API 時才需要採用這種方法，對只有 64 位元版本的全新 API 則不需要這樣做。

　　

3.3 程式集和 DLL 的命名

 

3.4 命名空間的命名

　　要用公司名稱作為命名空間的首碼，這樣就可以避免與其它公司使用相同的的名字了。

　　要使用穩定的、與版本無關的產品名稱作為命名空間的第二層。

　　不要根據公司的組織架構來決定命名空間的階層，因為公司內部組織的名稱一般經過一段時間後可能會改變。

　　要使用 PascalCasing 大小寫風格，並用點號來分隔命名空間的各部分。如果商標使用了非傳統的大小寫風格，那麼即使改風格與常規的大小寫風格相悖，也還是應該遵循商標的大小寫風格。

　　考慮在適當地時候在命名空間中使用複數形式。

　　不要用相同的名字來命名命名空間以及位於該命名空間的類型。

　　不要引入太一般化的類型名，比如： Element、Node、Log 以及 Message。

　　不要給類型起會與核心命名空間中的任何類型產生衝突的名字。

　　不要給類型起會與同一技術中的其它類型產生衝突的名字。

　　不要在技術命名空間和應用程式模型命名空間的類型之間引入類型名衝突（除非不打算將該技術與該應用程式模型一起使用）。

　　

3.5 類、結構和介面的命名

　　要用名詞或名詞短語來給類和結構命名。在命名時要使用 PascalCasing 大小寫風格。這使類型名和方法區分開，後者採用動詞短語來命名。

　　要用形容詞短語來給介面命名，在少數情況下也可以使用名詞或名詞短語。

　　不要給類名加首碼。

　　考慮在衍生類別的末尾使用基類的名字。

　　要讓介面的名字以字母 I 開頭，這樣可以顯示出該類型是一個介面。

　　要確保一對類/介面的名字只相差一個“I”首碼，如果該類是該介面的標準實現。

　　要用描述性的名字來命名泛型型別參數-除非一個字母就可以說明含義就無需使用描述性的名字。

　　考慮用單個字母 T 來具名引數類型 - 如果類型只有一個型別參數並且型別參數只有一個字母。

　　要給描述性的型別參數名加上 T 首碼。

　　考慮在型別參數名中顯示出施加於該型別參數上的約束。

　　要遵循描述的規範 - 如果要從 .NET 架構的類型派生新類，或者要實現 .NET 架構中的類型。

　　要用單數名詞來命名枚舉類型，除非它表示的是位域。

　　要用複數名詞來命名表示位域的枚舉類型，這樣的枚舉類型也成為標記枚舉。

　　不要給枚舉類型的沒名字添加“Enum”尾碼。

　　不要給枚舉類型的名字添加“Flag”或“Flags”尾碼。

　　不要給枚舉類型值的名字添加首碼。

 

3.6 類型成員的命名

　　要用名詞、名詞短語或形容詞來命名屬性。

　　不要讓屬性名稱看起來與“Get”方法的名字相似。

　　要用描述集合中項目短語的複數形式來命名集合屬性，而不要使用短語的單數形式加“List”或“Collection”尾碼。

　　要用肯定性的短語（CanSeek 而不是 CantSeek）來命名布爾屬性。如果有協助，還可以有選擇性地給布爾屬性添加“Is”、“Can”或“Has”等首碼。

　　考慮用屬性的類型名來命名屬性。

　　要用動詞或動詞短語來命名事件。

　　要用現在時和過去時來賦予事件名之前和之後的概念。

　　不要用“Before”和“After”首碼或尾碼來區分前置事件和後置事件。

　　要在命名事件處理函數（用作事件類型的委託）時加上“EventHandler”尾碼。

　　要在事件處理函數中用 sender 和 e 作為兩個參數的名字。

　　要在命名事件的的參數類時加上“EventArgs”尾碼。

　　要在命名欄位時使用 PascalCasing 大小寫風格。

　　要用名詞、名詞短語或形容詞來命名欄位。

　　不要給欄位名稱加首碼。

 

3.7 參數的命名

　　要在具名引數時使用 camelCasing 大小寫風格。

　　要使用具有描述性的參數名。

　　考慮根據參數的意思而不是參數的類型來具名引數。

　　要使用 left 和 right 來命名重載二元操作符的參數 - 如果參數沒有具體的含義。

　　要使用 value 來命名重載一元操作符的參數 - 如果參數沒有具體的含義。

　　考慮使用有意義的名字來命名重載操作符的參數 - 如果這樣做可以清晰地表達名字的意義。

　　不要在命名重載操作符的參數時，使用縮寫或數字編號。

　　

3.8 資源的命名

　　要在命名資源鍵時使用 PascalCasing 大小寫風格。

　　要使標識符的名字具有描述性而不是使名字變短。

　　不要使用各主要 CLR 程式設計語言特有的關鍵字。

　　要在命名資源時僅使用字母、數字和底線。

　　要在命名異常訊息的資源時遵循下面的命名規範。

　　

 

【出處】http://www.cnblogs.com/liqingwen/p/7152673.html 

 

《.NET 規範》第 3 章 命名規範