小驼峰法（camel方法）变量一般用小驼峰法标识。

　　第一个单词以小写字母开始；第二个单词的首字母大写或每一个单词的首字母都采用大写字母，

例如：myFirstName、myLastName

　　大驼峰法（Upper Camel Case）也称为：帕斯卡命名法：（pascal方法）常用于类名，函数名，属性，命名空间。

　　相比小驼峰法，大驼峰法把第一个单词的首字母也大写了。例如：public class DataBaseUser

　　下面是分别用骆驼式命名法和下划线法命名的同一个函数：　　

　　基本原则是：变量名=属性+类型+对象描述。

　　匈牙利命名法关键是：标识符的名字以一个或者多个小写字母开头作为前缀；前缀之后的是首字母大写的一个单词或多个单词组合，该单词要指明变量的用途。

　　匈牙利命名法通过在变量名前面加上相应的小写字母的符号标识作为前缀，标识出变量的作用域，类型等。这些符号可以多个同时使用，顺序是先m_（成员变量），再指针，再简单数据类型，再其他。　　例如：m_lpszStr, 表示指向一个以0字符结尾的字符串的长指针成员变量。

优点： （1）匈牙利约定可以使得在命名中容易产生定义的区域变得准确清楚。特别是约定中对 First，Min，Last，Max 和 Lim 的准确区分在实际中是尤其有帮助的。

（2）匈牙利约定可以使人对编译程序无法检查的抽象数据类型进行检查：cpaReformat[i]很可能是错误的，因为cpaReformat 不是数组，而 apaReformat[i]则可能是正确的，因为 apaReformat[i]是数组。   

（3）匈牙利约定可以在类型不严格的语言或环境中对类型进行说明。例如，在 Windows 环境下编程时，需要你放弃许多类型，这极大地限制了编译程序进行严格类型检查的能力。而建立约定则可以对环境的这一弱点作出补偿，匈牙利约定还可以使名称更简洁，可以用 CMedals 而不用 TotalMedals 来代表奖牌的数量，使用 pNewScore，而不是用 NewScorePtr 命名一个新分数指针。

缺点： （1）一些版本的匈牙利约定事实上忽视了用抽象数据类型作为基本类型。它们以程序语言中整型、长整型、浮点数和字符串为基础来建立基本类型。

（2）匈牙利约定基本类型事实上是没有什么价值的，因为它使得程序员陷入对类型进行人工检查的困扰之中，而不是让编译程序对类型进行更加快速而又准确的检查。这种形式匈牙利约定的另一个问题是它把数据的意义与其表现联系在一起。比如，说明某一变量是整型的，把它改为长整型的时，不得不改动这一变量的名称。

（3）匈牙利约定的最后一个问题是它鼓励了懒惰、不含什么信息的变量名的出现。当程序员用hwnd 来命名对窗口的操作时，往往忽视了他所指的到底是哪种窗口、对话框、菜单还是帮助区的屏幕？显然用 hwndmenu 要比 hwnd 清楚得多。以变量的意义为代价来获得对其类型的精确描述显然是愚蠢的。不过好在可以用加限定词的办法来同时获得完整的意义和精确的类型。