變量的命名方法

1、引言

隨着計算機技術的不斷髮展，計算機計算能力的提升催生了大量大型軟件的出現，大型軟件的代碼量動輒成千上萬行，甚至數十萬行。隨着代碼量的指數級增長，以前未曾注意的“小”問題也明顯被放大。比如代碼中的變量命名，這屬於我們印象中的“小”問題，對於代碼量小的程序來說，將變量命名爲a、b、aa、string1、string2等類型，並不會影響程序的編寫及閱讀，如果是代碼量大的程序，如果通篇都是字母、*1、*2等類型的變量名稱，不僅在編寫代碼時容易出錯，而且極不利於程序的閱讀，那程序的後期維護就更難上加難了！所以如何有效地解決這些“小”問題也成了亟需研究的內容。

本文主要研究的是在代碼編寫時的變量、函數命名法。目前存在的主流命名法主要有匈牙利命名法、駱駝命名法、帕斯卡命名法。下面就對這三種命名法進行詳細的介紹，並結合三種命名法的特點提出適合自己的命名規則。

2、匈牙利命名法

2.1、簡介

匈牙利命名法（Hungarian Notation），是由1972年至1981年在施樂公司工作的程序員查爾斯.西蒙尼（Charles.Simony）,此人後來成爲微軟的總設計師，因其祖籍是匈牙利，故有此名。

匈牙利命名法在國內之所以這麼有名是因爲當時微軟對其推崇備至。在上世紀90年代，MFC的出現影響了一代代程序員，而MFC中各種類的命名是以匈牙利命名法命名的，再加上當時微軟出了不錯的書《Windows程序設計》推波助瀾，而同時呢，國內UNIX編程風格氛圍不強，這種命名法幾乎成了國內變量命名法的標準。這就導致在現在的某些書籍或者項目中推薦使用匈牙利命名法

2.2、規則

匈牙利命名法的基本規則是：變量名=屬性+類型+對象描述，其中每一個對象的名稱都要求有明確含義，可以是對象名字全程或者一部分，同是要基於容易記憶理解的原則。

變量名中各部分的使用規範：

1） 屬性部分

變量名的屬性主要是表明該變量的屬性，比如變量的作用範圍（全局\局部）、成員變量、或者靜態變量等。相關的表示如下：

全局變量	g_
常量	c_
類的成員變量	m_
靜態變量	s_

2） 類型部分

類型值得是變量的類型，如整型、浮點型、字符串等。部分表示如下：

數組	a	長整型	l
指針	p	布爾型	b
函數	fn	浮點型	f
無效	v	雙字節	dw
句柄	h	字符串	sz
短整型	n	雙精度浮點型	d
計數	cnt	字符	ch
整型	i	字節	by
字節	w	無符號	u

3） 描述部分

描述部分通常用來表示該變量描述的意義，即該變量所表示的含義，部分標識如下：

最大	Max	最小	Min
初始化	Init	臨時變量	Temp
源對象	Src	目的對象	Dest

4） 例子

變量定義的這些描述符號可以多個同時使用，順序一般是m_，再指針，再簡單數據類型，再其它。

hwnd: h類型描述，表示句柄；wnd是變量的對象描述，表示窗口，所以hwnd表示窗口句柄。

pfnEatApple: pfn是類型描述，表示指向函數的指針；EatApple是變量對象描述，所以pfnEatApple表示指向EatApple函數的函數指針變量。

m_lpszStr: m_表示是成員變量；l表示長整型；p表示指針；sz表示的是字符串；Str是對象描述；所以m_lpszStr的含義就是表示指向一個字符串的長指針成員變量。

由此可見，匈牙利命名法通過在變量名前面加上相應的小寫字母的符號標識作爲前綴，標識出變量的作用域；前綴之後的是首字母大寫的一個單詞或單詞組合，主要指明變量的用途

2.3、匈牙利命名法存在的問題

匈牙利命名法是最有名但也是最有爭議的一種命名方法。隨着軟件代碼量的增加以及集成開發環境功能越來越強大，匈牙利命名法存在的問題也越來越突出。

2.3.1、HN命名法並不能幫助編譯器進行類型檢查也不加快開發速度

匈牙利命名法與其他命名法相比最主要的特點就是在變量名中指定了該變量的類型，在編譯器功能還不是很強大的年代，這種命名法確實有它獨到的優勢。

但是隨着編譯器功能越來越強大，在編寫代碼時，如果需要的話是可以顯示變量類型的，而且最主要也是把匈牙利命名法推下神壇的就是現代的集成開發環境都具有自動標記不匹配的類型的功能。

匈牙利命名法在編譯器做類型檢查時是多餘的。特別是對於C++這樣的強類型語言，一個提供類型檢查的語言在確定一個變量與其類型一致時，比人眼僅僅檢查變量的用法與變量名一致要強大得多

2.3.2、HN命名法保持前綴不利於代碼重構

在代碼的重構中，如果一個變量的類型改變了，那麼對於該變量而言需要把所有的該變量名修改，因爲該變量是把變量類型與變量名捆綁在一起 ，這樣極不利於代碼的移植。

一個衆所周知的例子就是WPARAM類型，以及在許多Windows系統函數聲明中使用的wParam參數。它原本是一個16位的類型（w描述的是Word類型），但在後來的操作系統中被改成了32位或64位，但仍保留原來的名字

2.3.3、HN命名法保持類型前綴會造成一定的冗餘成本

HN命名法中，變量將類型從單一地點（變量聲明處）複製到了多個地點（變量使用處），這會造成一定的冗餘成本，其一就是前面提到的維護代碼一致性的難題；其二就是佔用了額外的空間與時間；空間是指爲了保留這些含有變量類型的變量需要佔用額外的代碼行數，因爲這種命名法不可避免的會造成變量名長度的增加；時間是指，在閱讀代碼時每當看到變量總是先去解析變量的類型，然後纔會解析變量所代表的含義，這種“拐個彎”的想法總會造成在閱讀代碼時時間上的增加。比如定義了一個變量m_lpszName，我們首先回去解析m_lpsz所代表的含義，然後才知道原來這個變量代表的是名字。

在比如常見的字符串複製函數strcpy(pstrSource, pstrDest); 程序員需要從變量名中剔除pstr之類的前綴才能找到Source、Dest，才能理解變量的含義。相比strcpy(Source, Dest); 由於strcpy函數本身它已經規定了參數的類型，對於程序員來說只要一看到這個函數就會知道這兩個參數的類型，所以，大部分情況下是沒有必要按照HN命名法爲變量命名的，也能避免一些不必要的冗餘

3、駱駝命名法

3.1、簡介

駱駝式命名法（CamelCase），又稱駝峯命名法。正如名稱CamelCase所表示的形式，是指混合使用大小寫字母來構成變量和函數的名字。

駝峯命名法就是以單個單詞或多個單詞組成變量或者函數的唯一標識符時，第一個單詞以小寫字母開始，第二個單詞以及後面的每一個單詞的首字母大寫，例如myFirstName、myLastName，這樣的變量名看上去就像駱駝峯一樣此起披伏，故此得名。

需要注意的是這些單詞組成的標識符必須具有一定的意義，比如說：int studentNum; 通過變量名就能直觀的看出變量所代表的意義，就學生數量，而程序員也可以根據變量名的意義大致猜測出變量類型，就向studentNum變量，既然是指學生數量，那肯定是整型數據了。

駝峯法有分小駝峯法、大駝峯法；

小駝峯法大多是用來標識變量，是駝峯法的常規用法，即第一個字母小寫，其他單詞首字母大寫，例如：

int myStudentCount;

大駝峯法又稱帕斯卡命名法，是把變量名稱的第一個字母也大寫。主要用於類名、函數名、屬性、命名空間等，例如：

class DataBaseUser;

void GetUserName();

4、帕斯卡命名法

帕斯卡（Pascal）命名法又稱大駝峯法，用法見上文

5、適合自己的命名法

匈牙利命名法、駝峯命名法、帕斯卡命名法皆是針對代碼編寫時爲了提高編碼質量和效率而提出的一種變量命名規範，這三種命名規範既有優點也有缺點，不能只使用着一種命名規範，要根據相關情況綜合使用這三種命名規範，主要目的還是爲了是變量名便於記憶識別。下面就根據我的相關經驗與認識談談我自己的命名規範

5.1、Persional Notation

1） 變量的命名使用小駝峯法；函數、類型名等非常規變量採用大駝峯法；這也是我目前已經採用的方法；

2） 匈牙利命名法中關於變量屬性的用法是可取的；在實際編寫代碼時回不可避免的用到全局變量，而在閱讀時，往往無法識別出全局變量，總是用上下文查找的方法，這樣很不方便，參考HN命名法中關於變量屬性的使用，覺得在變量命名中引入屬性的概念是很有幫助的。

全局變量	g_
常量	c_
類的成員變量	m_
靜態變量	s_

3） HN命名法中關於指針的用法。在定義變量時加上p_的前綴；

4） 中間變量加上Temp後綴；如airTemp

5） 對於作用範圍很小的變量，比如for循環中的漸變變量，可以使用極簡形式的變量如i、j等 ；

6） 對於C++STL中類型的變量，比如map、vector、list等，在聲明變量時加上對應類型的後綴，如Map、Vector、List。如airMessageMap

7） 對於線程函數，加上Thread後綴；如ServerThread()