匈牙利命名法

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

开头字母用变量类型的缩写，其余部分用变量的英文或英文的缩写，要求单词第一个字母大写。例如：

int iMyAge;  //“i”是int类型的缩写；
char cMyName[10];  //“c”是char类型的缩写；
float fMyHeight;  //“f”是float类型的缩写；

匈牙利命名法中常用的小写字母的前缀：

驼峰式命名法

小驼峰式命名法

第一个单词首字母小写，后面其他单词首字母大写。例如：

int myAge;
char myName[10];
float myHeight;

大驼峰式命名法（帕斯卡命名法）

每个单词的第一个字母都大写。例如：

int MyAge;
char MyName[10];
float MyHeight;

匈牙利命名法优缺点

优点

（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 清楚得多。以变量的意义为代价来获得对其类型的精确描述显然是愚蠢的。不过好在可以用加限定词的办法来同时获得完整的意义和精确的类型。

其他

还有些许其他的命名规范，如：下划线命名法，但是不是太常用，Android开发的资源文件中用的还是很多的。综合各方面考虑，驼峰式命名法比较好，优势明显，事实上，目前使用驼峰式命名法的人也真的越来越多了。