C#中的匈牙利符号
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/768255/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Hungarian notation in C#
提问by Jason
Before using C#, C++ was my primary programming language. And the Hungarian notation is deep in my heart.
在使用 C# 之前，C++ 是我的主要编程语言。匈牙利的符号在我的内心深处。
I did some small projects in C# without reading a C# book or other guidelines on the language. In those small c# projects I used something like
我在 C# 中做了一些小项目，而没有阅读 C# 书籍或有关该语言的其他指南。在那些小的 c# 项目中，我使用了类似的东西
private string m_strExePath;
Until I read something from SO that said:
直到我从 SO 中读到一些内容：
Do not use Hungarian notation.
不要使用匈牙利符号。
So why? Am I the only person that has m_strExePath or m_iNumber in my C# code?
所以为什么？我是唯一一个在我的 C# 代码中有 m_strExePath 或 m_iNumber 的人吗？
回答by Justin Niessner
No, you're not the only one who does it. It's just generally accepted that Hungarian notation isn't the best way to name things in C# (the IDE handles a lot o the issues that Hungarian notation tried to address).
不，你不是唯一这样做的人。人们普遍认为，匈牙利表示法并不是在 C# 中命名事物的最佳方式（IDE 处理了很多匈牙利表示法试图解决的问题）。
回答by Otávio Décio
If Hungarian notation is deep in your and your team's and your company's heart, by all means use it. It is no longer considered a best practice as far as I can read from blogs and books.
如果匈牙利表示法在您和您的团队以及您的公司的内心深处，一定要使用它。就我从博客和书籍中阅读的内容而言，它不再被视为最佳实践。
回答by James Black
If you hold the pointer over the variable in VS it will tell you what type of variable it is, so there is no reason to go with these cryptic variable names, esp as people that are coming from other languages may need to maintain the code and it will be an obstacle to easy reading.
如果你把指针放在 VS 中的变量上，它会告诉你它是什么类型的变量，所以没有理由使用这些神秘的变量名，尤其是因为来自其他语言的人可能需要维护代码和这将成为轻松阅读的障碍。
回答by Jon Skeet
You're not the only person, but I'd say it's relatively uncommon. Personally I'm not a fan of Hungarian notation, at least not in the simple sense that just restates the type information which is already present in the declaration. (Fans of "true" Hungarian notation will explain the difference - it's never bothered me that much, but I can see their point. If you use a common prefix for, say, units of length vs units of weight, you won't accidentally assign a length variable with a weight value, even though both may be integers.)
你不是唯一的人，但我会说这相对不常见。就我个人而言，我不是匈牙利符号的粉丝，至少不是简单意义上的只是重申声明中已经存在的类型信息。（“真正的”匈牙利符号的粉丝会解释这种区别——我从来没有那么困扰过，但我能理解他们的观点。如果你使用一个共同的前缀，比如，长度单位与重量单位，你就不会意外分配一个具有权重值的长度变量，即使两者都可能是整数。）
However, for private members you can pretty much do what you want - agree with your team what the naming convention should be. The important point is that if you want your APIto fit in with the rest of .NET, don't use Hungarian notation in your public members (including parameters).
但是，对于私人成员，您几乎可以做您想做的事 - 与您的团队达成一致的命名约定。重要的一点是，如果您希望API适合 .NET 的其余部分，请不要在公共成员（包括参数）中使用匈牙利表示法。
回答by Gavin Miller
When doing user interface design, I have found it very useful to maintain Hungarian notation. Items like text boxes, labels and drop down lists are much easier to quickly understand and often you get repeating control names:
在进行用户界面设计时，我发现保持匈牙利符号非常有用。诸如文本框、标签和下拉列表之类的项目更容易快速理解，而且您经常会得到重复的控件名称：
lblTitle = Label
txtTitle = TextBox
ddlTitle = DropDownList
To me that's easier to read and parse. Otherwise, Hungarian notation doesn't fit in because of the advances in IDE's, specifically Visual Studio.
对我来说，这更容易阅读和解析。否则，由于 IDE（特别是 Visual Studio）的进步，匈牙利表示法不适合。
Also, Joel on Software has an excellent article related to Hungarian notation titled: Making Wrong Code Look Wrongwhich makes some good arguments forHungarian notation.
此外，Joel on Software 有一篇与匈牙利符号相关的优秀文章，标题为：使错误的代码看起来是错误的，它为匈牙利符号提供了一些很好的论据。
回答by kloucks
unless you are using a text editor rather than the VS IDE there is little value to hungarian notation and it impeeds rather than improves readability
除非您使用的是文本编辑器而不是 VS IDE，否则匈牙利表示法没有什么价值，它会阻碍而不是提高可读性
回答by Patrick Peters
One downside of Hungarian notation is that developers frequently change the type of variables during early coding, which requires the name of the variable to also change.
匈牙利表示法的一个缺点是开发人员在早期编码期间经常更改变量的类型，这需要变量的名称也更改。
回答by Richard Ev
The only two areas where I currently see any form of Hungarian notation are:
我目前看到任何形式的匈牙利符号的仅有的两个领域是：
- Class member variables, with a leading underscore (e.g.
_someVar) - WinForms and WebForms control names (
btnfor Button,lblfor Label etc)
- 类成员变量，带前导下划线（例如
_someVar） - WinForms 和 WebForms 控件名称（
btn用于按钮、lbl标签等）
The leading underscore on member variables seems like it is here to stay with us for a while longer, but I expect to see the popularity of Hungarian on control names to wane.
成员变量上的前导下划线似乎还存在一段时间，但我希望看到匈牙利语在控件名称上的流行度会减弱。
回答by 17 of 26
Joel Spolsky has a really good articleon this topic. The quick summary is that there's two types of Hungarian notation that are used in practice.
Joel Spolsky 有一篇关于这个主题的非常好的文章。简短的总结是，在实践中使用了两种类型的匈牙利符号。
The first is "Systems Hungarian" where you specify the variable type using a prefix. Things like "str" for string. This is nearly useless information, especially since modern IDEs will tell you the type anyway.
第一个是“Systems Hungarian”，您可以在其中使用前缀指定变量类型。像字符串的“str”之类的东西。这几乎是无用的信息，尤其是因为现代 IDE 无论如何都会告诉您类型。
The second is "Apps Hungarian" where you specify the purposeof the variable with a prefix. The most common example of this is using "m_" to indicate member variables. This can be extremely useful when done correctly.
第二个是“Apps Hungarian”，您可以在其中使用前缀指定变量的用途。最常见的例子是使用“m_”来表示成员变量。如果正确完成，这将非常有用。
My recommendation would be to avoid "Systems Hungarian" like the plague but definitely use "Apps Hungarian" where it makes sense to. I suggest reading Joel's article. It's a bit long winded but explains it much better than I could.
我的建议是避免像瘟疫一样使用“Systems Hungarian”，但在有意义的地方绝对使用“Apps Hungarian”。我建议阅读乔尔的文章。它有点冗长，但比我能更好地解释它。
The most interesting part of this article is that the original inventor of Hungarian notation, Charles Simonyi, created "Apps Hungarian" but his paper was horribly misinterpreted and the abomination of "Systems Hungarian" was created as a result.
这篇文章最有趣的部分是，匈牙利符号的最初发明者 Charles Simonyi 创造了“Apps Hungarian”，但他的论文被严重误解，结果产生了令人憎恶的“Systems Hungarian”。
回答by JaredPar
You're certainly not the only person, but I do hope you're part of a declining trend :)
你当然不是唯一的人，但我确实希望你是下降趋势的一部分:)
The problem with Hungarian notation is that it's trying to implement a type system via naming conventions. This is extremely problematic because it's a type system with only human verification. Every human on the project has to agree to the same set of standards, do rigorous code reviews and ensure that all new types are assigned the appropriate and correct prefix. In short, it's impossible to guarantee consistency with a large enough code base. At the point there is no consistency why are you doing it?
匈牙利符号的问题在于它试图通过命名约定来实现类型系统。这是非常有问题的，因为它是一个只有人工验证的类型系统。项目中的每个人都必须同意同一组标准，进行严格的代码审查并确保所有新类型都分配了适当且正确的前缀。简而言之，不可能保证与足够大的代码库的一致性。在这一点上没有一致性，你为什么要这样做？
Furthermore tools don't support Hungarian notation. That might seem like a stupid comment on the surface but consider refactoring for instance. Each refactoring in a Hungarian naming convention system must be accompanied with a mass rename to ensure that prefixes are maintained. Mass renames are susceptible to all sorts of subtle bugs.
此外，工具不支持匈牙利符号。从表面上看，这似乎是一个愚蠢的评论，但请考虑重构。匈牙利命名约定系统中的每次重构都必须伴随大量重命名，以确保维护前缀。批量重命名容易受到各种细微错误的影响。
Instead of using names to implement a type system, just rely on the type system. It has automatic verification and tool support. Newer IDE's make it much easier to discover a variable's type (intellisense, hover tips, etc ...) and really remove the original desire for Hungarian Notation.
与其使用名称来实现类型系统，不如依靠类型系统。它具有自动验证和工具支持。较新的 IDE 使发现变量的类型（智能感知、悬停提示等）变得更加容易，并真正消除了对匈牙利表示法的原始需求。
