为匈牙利命名法正名

  这年头还讨论匈牙利命名法这种恶心的东西?心理变态,奥特曼。微软在C#中都建议不要使用这种源自微软的命名法。
  今天看到《more joel on software》，又一次批判了匈牙利命名法。"羞愧"的说我们项目中至今还用的是匈牙利老掉牙的丑陋命名法。
  先说是匈牙利命名法的几个主要问题吧。
  1.不够优雅
  2.对于面向对象的编程来说，应当关心成员是什么对象，而不是去关心它是什么类型。匈牙利命名法会迫使你去更多的关注实现细节，而不是设计抽象。
  3.当一个成员类型改变后，变得难以修改。比如说一个成员叫做m_dwHouseNumber表示一个人的房子数。为当上房奴而奋斗的你发现用4字节来表示个人房产数是件很闹心的事。于是你将它改为m_ucHouseNumber。比房子问题更麻烦的事来了。m_dwHouseNumber分散在多个文件中(MFC这种在面向对象早期建立的框架，随处可见到将成员变量定为public，然后到处使用，破坏封装性这种恶行),你得将所有使用m_dwHouseNumber的地方都改为m_ucHouseNumber。如果不改，会让你的人生变为杯具（亲身经历..）
  然后再为匈牙利命名法辩解一些。说一下它的好话：它最大或者说唯一的好处就是你能一下子看出这个字段占有多少字节。对于多人合作进行网络开发来说，有时候它会是福音。特别是文档的版本的1.5，而代码的版本已经更新到1.6的时候。很多时候代码就是最好的文档。并不是所有环境都有带智能提示功能的编辑器，甚至不支持多文档浏览。在这种环境下看代码是件很痛苦的事情，特别是看别人的代码。如果你在检查网络协议的时候忘了一个字段是几字节，你不得不去打开另外一个文件看看它的定义。对于我们这种只关心封装不关心继承的业务来说,把房子当作一个对象还是当作一个整数并不重要。
   再说一下上面的三个问题。
   问题1:对于追求优雅完美的程序员来说，抛弃匈牙利命名法吧。
   问题2：对于追求执行效率高于应对业务变化的工种来说,2不是太重要。
   问题3: 现在的重构工具都支持rename功能，不必战战兢兢的去使用文本替换功能。
   所以说匈牙利命名法还会长期存在我们项目中。虽然从本质上来说我不太喜欢这种命名法。但我们老大喜欢，而且也没有给我们带来过多的麻烦。