匈牙利命名规则

系统命名法与应用命名法的区别在于前缀的目的。

在系统匈牙利命名法中，前缀代表了变量的实际数据类型。例如：

lAccountNum：变量是一个长整数（"l"）;
arru8NumberList：变量是一个无符号8位整型数组（"arru8"）;
szName：变量是一个零结束字符串（"sz"），这是西蒙尼最开始建议的前缀之一。
匈牙利应用命名法不表示实际数据类型，而是给出了变量目的的提示，或者说它代表了什么。

rwPosition：变量代表一个行（"rw"）。
usName：变量代表一个非安全字符串（"us"），需要在使用前处理。
strName：变量代表一个包含名字的字符串（"str"）但是没有指明这个字符串是如何实现的。
西蒙尼建议的大多数前缀都是自然语义的，但不是所有。下面几个是来自原始论文的： [1]

pX是指向另一个X类型的指针，这包含非常少的语义信息。
d是一个前缀表示两个值的区别，例如，dY可能代表一个图形沿Y轴的距离，而一个仅仅叫做y的变量可能是一个绝对坐标。这完全是自然语义的。
sz是一个无结束或零结束的字符串。在C中，这包含一些语义信息，因为它不是很明确一个char*类型的变量是一个指向单个字符的指针，还是一个字符数组，或是一个零结束字符串。
w标记一个变量是一个字。这基本上没有包含什么语义信息，因此大概会被当成是系统命名法。
b标记了一个字节，和w对比可能有一些语义信息，因为C语言中，只有字节大小的数据是char型的，因此这些有时候被用来保存数值。这个前缀也许可以明确某个变量保存的是应该被看作是字母（或更一般的字符）的数值还是一个数字。
由于这种命名法通常使用小写字母开头用来助记，但是并没有对助记符本身作规定。有几种被广泛使用的习惯（见下面的示例），但是任意字母组合都可以被使用，只要它们在代码主体中保持一致就可以了。

在使用匈牙利系统命名法的代码中有时候也可能包含系统匈牙利命名法，即在描述被单独以类型方式定义的变量时使用。

示例[编辑]bBusy：布尔型
cApples：项目计数
dwLightYears：双字（系统）
fBusy：布尔型（标记）
nSize：整型（系统）或计数（应用程序）
iSize：整型（系统）或索引（应用程序）
fpPrice：浮点数
dbPi：双精度浮点数（系统）
pFoo：指针
rgStudents：数组或范围
szLastName：零结束字符串
u32Identifier：无符号32位整型（系统）
stTime：时钟结构
fnFunction：函数名
对于指针和数组来说，它们实际上并不是数据类型，因此通常在助记符后面跟着实际元素的类型。

pszOwner：指向零结束字符串的指针
rgfpBalances：浮点值的数组
由于匈牙利命名法可以被应用在任何程序设计语言和环境中，因此被微软广泛用在C语言中，特别是在Microsoft Windows里。由此一来，许多常见的匈牙利命名法的结构都和Windows紧密相关：

hwndFoo：窗口句柄
lpszBar：指向零结束字符串的长指针
这种命名法又是在C++中被扩展而包含变量的作用域，由一个下划线隔开：

g_nWheels：全局命名空间的成员，整型
m_nWheels：结构体／类成员，整型
系统匈牙利命名法的优点[编辑]（其中一些只适用于系统匈牙利命名法） 支持者声称匈牙利命名法的好处包括：[1]

从名字中就可以看出变量的类型
拥有类似语义的多个变量可以在一个代码块中使用：dwWidth，iWidth，fWidth，dWidth
变量名在仅仅知道他们的类型时可以被轻易记住
可以使变量名更加一致
决定一个变量名的时候可以更机械化，更快
不合适的类型转换和操作可以在阅读代码的时候被检测出来
在那些数字被当作字符串处理的基于字符串的语言中非常有用（例如Tcl）
在匈牙利应用命名法中，变量名确保不会犯以下错误：
heightWindow = window.getWidth()
在使用动态类型语言或完全无类型的语言编程时，关于类型的修饰可以更简化。这种语言一般不包含类型修饰（或者可选），因此唯一可以看出哪些类型是被允许的只有名字本身、文档以及通过阅读代码来明白它们在做什么。在这些语言中，包含对于变量类型的指示可能会有助于程序员。就像上面提到的，匈牙利命名法扩展了这样的语言（BCPL）。
在包含许多全局对象的复杂程序中（VB/Delphi Forms），拥有一个基本的前缀命名法可以简化在编辑器中查找组件的工作。按btn<Ctrl-Space>可以使编辑器弹出一个Button对象的列表。
匈牙利系统命名法的缺点[编辑]批评者认为：

匈牙利命名法在编译器做类型检查时是多余的。一个提供类型检查的语言在确定一个变量与其类型一致时，比人眼仅仅检查变量的用法与变量名一致要强大的多。
一些现代的集成开发环境，如Visual Studio在需要时可以显示变量类型，并且自动标记不匹配的类型。使用这种命名法完全没有必要。
匈牙利命名法在被用作代表多个属性的时候会造成困惑，如 a_crszkvc30LastNameCol：一个常量引用参数，保存了一个varchar（30）类型的数据库列LastName的内容，而这列又是这个表的主键的一部分。
在代码更改后可能造成不一致。如果一个变量的类型改变了，不是变量名的修饰与新的类型不一致，就是变量名必须被改变。
由于变量名和类型捆绑在一起，因此不利于代码的移植。一个典型的众所周之的例子就是WPARAM类型，以及在许多Windows系统函数声明中使用的wParam参数。它原本是一个16位的类型，但是在后来的操作系统中被改成了32位或64位，但仍保留原来的名字（它实际的基础类型是UINT_PTR，即一个大小足够保存一个指针的无符号整型）。
大多数时候，看到一个变量就意味着知道了它的类型。但是，如果你不知道一个变量是干什么的，知道了它的类型也没什么帮助。
.NET Framework，微软新的软件开发平台，除了接口类型一般不适用匈牙利命名法。在.NET中，习惯在接口类型前放一个I（例如Windows Forms中的IButtonControl接口。）.NET Framework指导方针建议程序员不要用匈牙利命名法，但是没有指明不要用系统匈牙利命名法还是匈牙利应用命名法，或者是两者都不要用。[2]与此对比，Java的标准库中连接口类型也不加前缀。[3]