自己上课的老师推荐我们使用，但我发现在使用的过程中，随着程序的复杂性，

命名会变得越来越长，而且写的时候容易少打字母之类的，累个半死．

这种命名法好处可以直接明了知道类型．

还是自己查资料看看怎么命名比较好．

看了作者的原文，综合来看，这种方法适合特定的编程类型．

如：支持泛型编程和面向对象编程（这两种编程范型都是基于类型和参数来选择合适的操作）的语言来说，它却是完全不合适的。

参考资料Ｃ／Ｃ＋＋高质量编程，Thecprogramminglanuage，作者的网站

英文翻译如下：

不，我并不推荐“匈牙利命名法”。我认为“匈牙利命名法”（在变量名中嵌入类型的缩写）是一种对隐式类型语言来说行之有效的技巧，但对支持泛型编程和面向对象编程（这两种编程范型都是基于类型和参数来选择合适的操作）的语言来说，它却是完全不合适的。在这种情况下，“把对象的类型用作名字的一部分”不仅复杂化了抽象，更限制了抽象的程度。在不同程度上，我对各种将语言技术细节信息（例如：作用域、存储类型、语法类别）嵌入（变量）名字的方案都持有保留态度。我同意在某些情况下，将类型提示嵌入变量名会很有帮助，但大多数情况下，特别是随着软件的发展，这会导致维护危机，甚至会严重损害优秀的代码。像躲避瘟疫一般地远离它吧。

因此，我不喜欢根据类型命名变量；我喜欢并推荐什么？根据功能命名变量（函数、类型等等）。选择有意义的名字；亦即，选择有利于别人读懂你的程序的名字。甚至你自己往往也会难以理解你的程序到底是要干嘛用的，如果你在程序中胡乱使用“易于拼写”的名字，例如x1、x2、s3、p7等等。缩写词和首字母缩写词很容易混淆视听，所以应该“省点儿”用这种词。首字母缩写词更是应该尽可能地避免。比如mtbf、TLA、myw、RTFM、NBV等等。此时此刻，它们的含义可能显而易见。但几个月过后，任谁也不敢担保一定不会忘掉其中任何一个（的含义）。

短小的名字，例如x和i，如果按传统习惯来用的话，是有意义的；亦即，x只被用作局部变量或者参数，而i用作循环计数器。

不要使用过长的名字；它们难以拼写，并使代码行变得很长，以致不能完全显示于屏幕上，而且也不易于阅读。下面这些变量名看起来不错：

partial_sumelement_countstaple_partition

这两个就太长了点：

the_number_of_elementsremaining_free_slots_in_symbol_table

我更喜欢使用下划线来分隔标识符（例如element_count）里的单词，而非替换使用大小写，例如elementCount和ElementCount。名字里的字母绝对不要全部都用大写（例如BEGIN_TRANSACTION），因为全部大写习惯上是用于命名宏的。即使你不用宏，但其他人也许会在他们的头文件中引用你的头文件。命名类型时，最好大写首字母（例如Square和Graph）。C++语言和标准库都不使用大写字母，因此int非Int，string非String。这样，你就能很容易地辨认出哪些是标准类型，哪些是你定义的类型。 [Page]

避免使用易于拼错、看错或混淆的名字。例如：

namenamesnameS
foof00
flf1fIfi

字符0、o、O、1、l以及I特别容易引起问题。

通常，命名习惯的选择仅受限于局部的风格规则。切记，保持风格的一致性常常比使用你认为最好的方式处理各种小细节更为重要。