對框架中識別符號的名字來說,達到一目了然的效果很重要。識別符號的名字應該能夠清楚的表達每個成員是做什麼,以及每個型別和引數代表什麼。名字應該和應用場景、系統的邏輯組成或物理組成以及為人熟知的概念相對應,而不應該與技術或架構相對應。
要為識別符號選擇易於閱讀的名字。
要更看重可讀性,而不是簡潔性。以前的程式語言識別符號命名之所以簡單,是因為那時候的pc記憶體和磁碟的空間都很小,大家不得不盡量的壓縮,對於現在的pc,大家就沒必要糾結這個問題了,所以相對於簡潔性,可讀性更重要。
不要使用下劃線、連字元以及其他任何既非字母數字的字元。對於私有字段,我還是比較喜歡在識別符號前加個下劃線字首。
不要使用匈牙利命名法(基本原則:變數名=屬性+型別+物件描述)。在c和c++中這個命名方式比較常見。
避免使用與廣泛使用的程式語言的關鍵字有衝突的識別符號。雖然在c#中可以通過新增「@」字首的方式將關鍵字作為識別符號來使用,但在使用方法時,用轉義序列要比不轉義序列麻煩得多。在 asp.net mvc開發模式razor 語法中,行內表示式(變數和函式)都是以「@」開頭的。所以不建議用這個加「@」符號的命名方式。
不要使用未被廣泛接受的縮寫詞和單詞首字母縮寫詞作為識別符號名字的組成部分。那麼什麼才是廣泛的被接受的縮寫詞呢,一種測試方式是,直接將該縮寫詞輸入到搜尋引擎中,如果返回的前幾個結果都是和縮寫詞本意相關的結果,那麼該縮寫詞就有資格被稱為眾所周知。
要給型別名使用語義上有意義的名字,而不要使用語言特有的關鍵字。
要使用clr的通用型別,而不要使用語言特有的別名(如果除了型別之外,識別符號沒有其他的語義)。
要使用比較常見的名字,比如value和item,而不要重複型別的名字(如果除了型別之外,識別符號沒有其他的語義,且引數的型別無關緊要)。如:void write(int value);
當乙個已有型別需要新增新的特性的時候,我們無法直接對已有型別的成員進行擴充套件或過載,為此,只能是通過新增不同名字的新成員。
要在建立已有api的新版本時使用與舊版api相似的名字。
要優先使用字尾而不是字首來表示已有api的新版本。在寫c#的擴充套件方法時,比較常用。
考慮使用全新但有意義的識別符號,而不是隨便給已有識別符號加個前字尾。
要使用數字字尾表示已有api的新版本(如果已有api的名字是唯一有意義的名字,即它是乙個工業標準,不適合新增字尾或改名)。
要在引入64位整數而非32位整數進行操作的新版本api時用「64」字尾。當已有32位的api存在時採用這種方式,對只有64位版本的全新api則不需要這樣做。
命名規範 C 命名規範約定
命名規則約定 序 號描述示例 1類命名混合使用大小寫,首字母大寫 classname 2型別定義,包括列舉和typedef,混合使用大小寫,首字母大寫 typename 3區域性變數混合使用大小寫,且首字母小寫,名字與底層資料型別無關,且應該反映其所代表的事物 localvariable 4子程式引...
Google C 程式設計規範 命名約定(部分)
1.通用命名規則 具備描述性,適當縮寫,型別和變數應該是名詞,函式名可以用 命令性 動詞 int num errors good.int num completed connections good.int price count reader 無縮寫 int num errors num 是乙個常...
mysql基本約定與命名規範
一 約定 1 如無特殊需求,所有表使用innodb引擎 2 如無特殊需求,所有主鍵均為自增型別 3 如無特殊需求,所有欄位均為not null,並給定預設值 4 所有欄位均設定備註,列舉字段需要說明每個列舉值的意義 5 在能滿足取值範圍的情況下,選擇占用儲存空間最小的資料型別。如布林值使用tinyi...