在现实项目中，已经因为这种怪异的命名方法碰到问题了。不同背景，不同年龄，只要是不同的人，就有不同的理解。好多次开会开到一半，才发现此I非彼I，此P非彼PStrange 写了：我一直觉得，没什么不好1。造成理解混淆。一个I，其实可以代表Interface，也可以代表Integer，事实上，早期的I是代表Integer，后期的I是代表 Interface，人为产生软件开发代沟。更不要说P有的代表Poiter，有的代表一个自己的Class叫Person的事情了
2。 完全没有必要。这种写法最主要是早期编辑器非常不好用的情况下，为了清晰而产生的。可是正如1所言，现在已经会产生混淆了。当下用emacs或者vim或者任何一种IDE都可以很清楚地标识类型，何苦自己为难自己
3。以后再说，我想看看你们说的好处在哪里
但至少觉得这个1和2不成立，想听听下面的
网上一般认为不好也就是繁琐，其他也没啥
1。
每个项目有每个项目的coding style，看明白了之后，这个项目中不会发生混淆，除非程序没完全按照代码规范来做
一个项目中i既代表integer又代表interface的话，只能说代码规范不好了
退一步说，如果觉得这个辅助的信息没用，读代码的时候完全可以自己忽略，就当没看见，这样和一个普通的变量名称除了繁琐以外有什么特别的区别？
2。
基本没必要还有道理，完全没必要就太绝对了
如果代码打印出来呢？
即使是vim，想要简单方便的很清楚地标识类型的方法是没有的，如果有，一定请教我一下
vs2005记得也没有能直接从ide中直接表示变量类型的方法
3。
我认识的匈牙利的缺点
繁琐，不方便修改。变量长度变长，如果修改变量类型的话，改动大
但是，这个到正是现代ide所能弥补的一点
ide或者emacs/vim都有补完，有方便的搜索/替换功能
4。
所以，虽然网上骂匈牙利命名法的一片，但我觉得，这也只是一个命名法，说不上多好，但也说不上多差
根据程序的需要，用/不用，或者用部分，都是合理的选择
至于说IDE的代码类型标识功能，就是用不同颜色不同字体，一目了然。而打印出来，非要这么说，我也只能强词夺理一把，我还能用粗体黑体斜体和他们的组合来标识不同类型呢。Javadoc和Oxygendoc都能根据不同类型用不同颜色和字体标识，你用过的话就知道了
至于其他的，另外一个麻烦是可读性差。这个相当主观。在没有更好的命名方法出现之前，这不是问题。但吃过山珍之后，菜渣实在吃不下去
