《.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 則不需要這樣做。

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