匈牙利命名法

从事Windows下C/C++编程的人极可能遇到过相似nCount、stPerson这类风格的命名，这类风格的命名方式即为匈牙利命名法。

匈牙利命名法起源

匈牙利命名法(HungarianNotation)是由匈牙利裔美国人Charles Simony发明的，因为其单词排列顺序相似古怪的匈牙利姓名而得名。

实际上Charles Simony发明的是应用型匈牙利命名法，因为被曲解、以讹传讹，造成了咱们常见的系统型匈牙利命名法。文章开头的两个例子的风格来自于系统型匈牙利命名法。

这段历史在Joel on Software的《讓錯的程式看得出錯》有详细的介绍。

匈牙利命名法的构造

应用型匈牙利命名法和系统型匈牙利命名法都是经过前缀+对象描述的形式命名。

• 应用型匈牙利命名法
  前缀体现天然语义，主要是说明变量的应用属性或业务属性，抽象层次较高，如：

  若 Fahrenheit简称为fah，Celsius 简称为cel。下面的代码咱们一眼就能看出问题：
  int fahTemp = celThermometer;
  由于华氏温度和摄氏温度确定不能直接赋值，它们之间有转换关系，因此代码逻辑错误。

• 系统型匈牙利命名法
  而匈牙利系统命名法的前缀是为了说明变量的系统属性，最经常使用的是变量类型，上面的例子改写为：
  int iTemp = iThermometer;

  i标识变量类型是int，咱们很难看出其中的问题。

系统型匈牙利命名法的缺点

Windows开发的圣经《Windows 程序设计》初版大量使用了匈牙利命名法，因此系统型匈牙利命名法是Windows开发的事实标准。但随后的反对也愈演愈烈，在.net第一次发布时达到了高潮。微软在.net框架的《通用命名约定》中明确说明不建议使用匈牙利命名法。到如今，除了一些遗产代码，新的代码已经鲜见系统型匈牙利命名法了，并且《Windows 程序设计》第六版也不怎么使用匈牙利命名法了。

我认为其的几个缺点：

• IDE流行，特殊标注类型已没有必要
  有图有真相：

图中是Rust的代码段，guess后面的String是IDE推断出的，现代的工具已经很发达，能有效避免这种纯手工的标注。
其余语言同理。

• 抽象层次低，对问题排查没有用处

类型不一致致使的问题，在大多数语言的编译器都会产生错误或警告，人工作编译器的工做，没有必要。若是出错，大部分错误都是逻辑错误，这种类型标注帮不了什么忙。

• 适用面窄，跟不上发展

该命名法对于C++引入模板容器来讲就是灾难。引入的容器、迭代器等等不少，单字母已经没法表示，姑且用vec表示std::vector，那该模板类的实例std::vector<int>怎么表示？
即便能表示，std::vector<std::vector<std::vector<int>>>这个又怎么表示？

世上没有解决不了的问题，上述的问题确定也是能够解决的，只要制定相应的规则便可。问题是：这个成本能获得多大的回报。对于系统匈牙利命名法来讲，是没有必要的。

请关注个人公众号哦。