我最近开始学习Win32 API并且我讨厌匈牙利表示法（变量名中的那些愚蠢的前缀使得代码看起来很丑陋而且几乎不可读），但是你可能知道它绝对是在那里的所有地方！而且这个事实导致每个人都在他们的代码中使用它来保持一致性......我想这是一个愚蠢的问题，但无论如何，我也应该这样做吗？如果我不这样做，我的代码会变得奇怪或错误吗？
答案 0 :(得分：7)
似乎只是因为它是内部的Microsoft编码标准。我个人仅以原始（意图）的方式使用它，有时它是有意义的（例如，我preffer int size_kb而不是以千字节为单位定义大小的类型）。
答案 1 :(得分：5)
不 - HN的时间早已过去。事实上，它是第二系统类型的工件的一个很好的例子，它甚至在它被发明之前就已经过时了。很久以前，这个想法很有意义。当大多数编译器很少或没有进行类型检查时，手动检查类型的某种系统方法是一种至少有足够的价值值得考虑的想法。
虽然情况已经不是这样了（现在已经好几十年了）。即便是C编译器现在实际上也进行了真正的类型检查，几乎所有其他语言的编译器仍然可以做得更多。即使是十年前过时和平庸的编译器，也能比将类型信息编码为变量名更有效地完成这项工作，这使您有希望自己做。就此而言，即使是汇编程序现在也进行了足够的类型检查，以防止HN打算帮助解决许多类型的问题。
更糟糕的是，经常使用HN的人似乎认为会做一些有用的事情，因此他们会忽略编译器可能做的事情。结果，他们实际上最终得到的代码比他们根本没用过的代码差得多（脆弱，边缘错误）。大量的Microsoft代码显示出这种问题（例如，DWORD被用于各种不兼容的目的，并且人们认为将它们分配给另一个是有意义的，因为它们都有“dw”前缀）。
更糟糕的是，使用HN的代码比没有它的代码更难维护。作为一个主要的例子，看看当前代码仍然使用“lpsz”前缀的数量，即使“长”与“短”指针的概念在Windows 3.1中最后相关，接近20多年前的现在。从理论上讲，这应该在向大约15年前的32位代码迁移过程中得到解决 - 但是这需要大量的工作编辑代码才能获得基本没有任何好处（因为HN无论如何都是无价值的，有一个“正确的” psz并不比“不正确的”lpsz更好。
答案 2 :(得分：1)
如果您正在开发一个采用编码约定（HN或不是HN）的大型团队，那么关注，即使您讨厌它（下面有一个例外情况）。如果你只是为自己编写代码，或者你是一个对风格有更多 laissez faire 态度的团队，那么请选择让你的生活更轻松的原因。
编码约定（尤其是人为HN）的问题是每个人必须遵循它们;如果只有一半的团队无法正确使用HN，那么根本没有任何人可以获得任何好处，而你只是让你的代码更难以阅读。
话虽如此，不遵循使用i或带lpst的字符串作为整数变量前缀的愚蠢惯例;一点点愚蠢越快越好。 HN旨在传达更抽象的语义;目标是确定哪些对象对于特定操作是安全的或适当的（由ruslik链接到的软件文章上的Joel对其来说是一个很好的例子）。 IOW，变量名称应该表示用法，而不是类型，而HN是一种编码用法的尝试。
就个人而言，我更喜欢使用有意义的英语（或您选择的母语）名称来明确告诉您所处理的内容，而不是某些人工编码方案;从上面链接的Joel示例开始，我只使用rawName和encodedName等名称而不是usName和sName。它传达了大致相同的语义信息，并且读取效果也更好（IMO，无论如何）。
答案 3 :(得分：1)
Joel on Software有一篇很棒的文章解释了原因 （a）你应该讨厌你在windows Apps中看到的匈牙利人，以及 （b）为什么你应该认真考虑使用它。
如果您正在使用C开发，那么名为Apps Hungarian的符号的味道是必不可少的，它将帮助您编写正确的代码。 如果您使用类似C ++的安全OO语言进行开发，则不应使用匈牙利语，因为它不需要。
答案 4 :(得分：-1)