在C ++中,一般使用某種前綴來命名成員變量,以表示它們是成員變量,而不是局部變量或參數。 若是您來自MFC背景,則可能會使用m_foo
。 我也偶爾見過myFoo
。 html
C#(或者可能只是.NET)彷佛建議僅使用下劃線,例如_foo
。 C ++標準容許嗎? 數組
是的,下劃線能夠在標識符的任何地方使用。 我相信規則是:第一個字符中的az,AZ,_中的任何一個,其後幾個字符中的+ 0-9。 函數
下劃線前綴在C代碼中很常見-單個下劃線表示「專用」,一般保留雙下劃線以供編譯器使用。 測試
從MSDN : spa
在全部範圍內,C ++實現均保留在標識符的開頭使用兩個連續的下劃線字符(__)或使用單個下劃線後跟一個大寫字母。 對於具備文件範圍的名稱,應避免使用前導下劃線後跟小寫字母,由於這可能與當前或未來的保留標識符衝突。 設計
這意味着您可使用單個下劃線做爲成員變量前綴,只要其後跟一個小寫字母便可。 code
這顯然來自C ++標準的17.4.3.1.2節,可是我找不到在線完整標準的原始資料。 htm
另請參閱此問題 。 字符串
規則(在C ++ 11中未更改): get
std
名稱空間中的全部內容均保留。 (不過,您能夠添加模板專長。) 根據2003 C ++標準:
17.4.3.1.2全局名稱[lib.global.names]
某些名稱和函數簽名集始終保留給實現:
- 每一個包含雙下劃線(
__
)或如下劃線後跟大寫字母(2.11)開頭的名稱都保留給實現以供任何使用。- 每一個如下劃線開頭的名稱都保留給實現,以用做全局名稱空間中的名稱。 165
165)這些名稱也保留在命名空間
::std
(17.4.3.1)中。
因爲C ++基於C標準(1.1 / 2,C ++ 03),而C99是規範性參考文獻(1.2 / 1,C ++ 03),這些也適用於1999 C標準:
7.1.3保留標識符
每一個標頭聲明或定義在其關聯的子節中列出的全部標識符,並可選地聲明或定義在其關聯的未來的庫指示子節中列出的標識符以及始終保留用於任何用途或用做文件範圍標識符的標識符。
- 如下劃線,大寫字母或另外一個下劃線開頭的全部標識符始終保留供任何使用。
- 在普通和標記名稱空間中,全部如下劃線開頭的標識符始終保留爲具備文件範圍的標識符。
- 若是包含任何關聯的標頭,則如下任何一個子節(包括未來的庫說明)中的每一個宏名均保留爲指定用途。 除非另有明確說明(請參閱7.1.4)。
- 在如下任何條款(包括未來的庫說明)中,全部具備外部連接的標識符始終保留爲具備外部連接的標識符。 154
- 在如下任何子節(包括未來的庫說明)中列出的每一個具備文件範圍的標識符都保留用做宏名,而且若是包含任何關聯的標頭,則在同一名稱空間中用做具備文件範圍的標識符。
沒有其餘標識符被保留。 若是程序在保留它的上下文中聲明或定義標識符(而不是7.1.4容許),或者將保留標識符定義爲宏名,則該行爲未定義。
若是程序刪除(使用
#undef
)上面列出的第一組中標識符的任何宏定義,則該行爲未定義。154)具備外部連接的保留標識符的列表包括
errno
,math_errhandling
,setjmp
和va_end
。
其餘限制可能適用。 例如,POSIX標準保留了不少可能以普通代碼顯示的標識符:
E
開頭的名稱後跟數字或大寫字母:
is
或to
開頭的小寫字母
LC_
開頭的名稱,後跟一個大寫字母
f
或l
結尾的現有數學函數的名稱
SIG
開頭且後跟大寫字母的名稱
SIG_
開頭,大寫字母的名稱
str
, mem
或wcs
開頭的名稱,後跟小寫字母
PRI
或SCN
開頭的名稱,後跟任何小寫字母或X
_t
結尾的名稱被保留
雖然如今將這些名稱用於您本身的目的可能不會引發問題,但它們確實增長了與該標準的將來版本衝突的可能性。
我我的只是不如下劃線開頭標識符。 個人規則的新增內容:不要在任何地方使用雙下劃線,這很容易,由於我不多使用下劃線。
在對本文進行研究以後,我再也不用_t
結束標識符,由於POSIX標準保留了該標識符。
關於以_t
結尾的任何標識符的規則使我感到很是驚訝。 我認爲這是POSIX標準(尚不肯定),須要澄清和官方章節。 這來自GNU libtool手冊 ,其中列出了保留名稱。
CesarB提供了指向POSIX 2004保留符號的如下連接,並指出「在此能夠找到許多其餘保留的前綴和後綴...」。 此處定義了POSIX 2008保留符號。 這些限制比上述限制更加細微。
避免名稱衝突的規則在C ++標準中(請參閱Stroustrup書),在C ++專家(Sutter等人)中也提到過。
由於我不想處理案件,而是想要一個簡單的規則,因此我設計了一個既簡單又正確的我的規則:
在命名符號時,若是知足如下條件,將避免與編譯器/ OS /標準庫衝突:
固然,將代碼放在惟一的命名空間中也有助於避免衝突(但不能防止邪惡的宏)
(我使用宏是由於它們是C / C ++符號的更多代碼污染,可是它能夠是從變量名到類名的任何東西)
#define _WRONG #define __WRONG_AGAIN #define RIGHT_ #define WRONG__WRONG #define RIGHT_RIGHT #define RIGHT_x_RIGHT
從n3242.pdf文件中(我但願最終的標準文本相似):
17.6.3.3.2全局名稱[global.names]
某些名稱和函數簽名集始終保留給實現:
—每一個包含雙下劃線_ _或如下劃線後跟大寫字母(2.12)開頭的名稱都保留給實現以供任何使用。
—每一個如下劃線開頭的名稱都保留給實現,以用做全局名稱空間中的名稱。
可是也:
17.6.3.3.5用戶定義的文字後綴[usrlit.suffix]
不如下劃線開頭的文字後綴標識符將保留,以供未來標準化。
defined in the global namespace... 最後一個子句使人困惑,除非您認爲若是在全局名稱空間中定義,則以一個下劃線開頭並以小寫字母開頭的名稱是能夠的...
至於問題的其餘部分,一般將下劃線放在變量名的末尾 ,以避免與內部任何內容發生衝突。
我什至在類和名稱空間中也能夠這樣作,由於我只須要記住一個規則(相比之下,「在全局範圍內名稱的末尾,在其餘地方名稱的開頭」)。