variables前缀（“匈牙利符号”）真的有必要了吗？
由于C＃是强types的，我们是否真的需要variables前缀？
例如
iUserAge iCounter strUsername 过去我曾经用过前缀，但是我没有看到任何好处 。
variables前缀（匈牙利语）真的有必要了吗？
没有！
事实上，微软自己的风格指南 （实践起源）现在推荐它。 特别是关于一般命名约定的部分，其中包括以下文字（粗体字，不less于）：
不要使用匈牙利符号。
我认为唯一适合弯曲标准和前缀variables的地方是：
-
控制名称：
txtWhatever– 而且我看到我不是唯一的。 好的是你可以在txtName旁边find像lblName这样的东西，而且你不需要进入NameLabel / NameTextBox方向。 -
类成员variables：
_whatever。 我已经尝试了m_和no前缀，并以简单的下划线结束。 m_更难打字，没有前缀有时会变得混乱（特别是在维修时，我知道你们都是在编写它的时候才知道他们的代码）
尽pipe如此，我没有发现任何一致的情况，即用types前缀variables会使代码更具可读性。
编辑：我没有阅读微软的指导方针。 不过，我认为在适当的情况下，编码风格可以进化和/或“弯曲”。 正如我上面提到的，我发现使用下划线前缀有用的试用和错误，并肯定比使用this.would无处不在的代码。
支持“演进”理论 – 回到.NET 1.x当微软发布编码准则时，他们build议使用骆驼shell来处理所有事情，甚至常量。 我现在看到他们已经改变了，并build议使用帕斯卡案例为常数或公共只读领域。
此外，即使.NET Framework类库目前也是m_和_和s_（尝试使用Reflector浏览实现）。 毕竟，只要项目中保持一致性，就取决于开发人员。
如果匈牙利的意思是“前缀types缩写”，如uCount或pchzName，那么我认为这种做法是不好的，幸好似乎正在从通用的淡出。
不过，我仍然认为前缀对范围非常有用。 在我的工作室，我们使用这个约定作为variables的前缀：
i_ // input-only function parameter (most are these) o_ // output-only function parameter (so a non-const & or * type) io_ // bidirectional func param _ // private member var (c#) m_ // private member var (c++) s_ // static member var (c++) g_ // global (rare, typically a singleton accessor macro)
我发现这是非常有用的。 func param前缀特别有用。 顺便说一句，在函数里面，你总是可以知道var从哪里来。 当我们想要修改它或者改变它的意思时，通常我们会把这个var复制到另外一个。
所以简而言之：现代工具不需要前缀types。 IDE负责识别和检查你的东西。 但基于范围的前缀对于可读性和清晰度非常有用。
Intellisense也有好处。 你可以inputi_ ctrl-space，并把所有的input参数传给func来select。 或者g_ctrl-space来获得你所有的单身人士。 这是一个节省时间。
不。 我们有没有需要？
匈牙利符号是丑陋的。 唯一的例外是接口，大多数人认为它是可以接受的。
Linus总结道：“将函数的types编码为名称（所谓的匈牙利符号）是脑损坏 – 编译器知道types并可以检查这些types，只会让程序员”
匈牙利符号只是增加了不必要的噪音代码，并与编译器types检查冗余。
是的，如果匈牙利语是按照原来的意思使用的，而不是微软所实施的。 就像上面的例子一样，它显示文本框和相应的标签为lblWhatever，txtWhatever。 用它来定义variables的使用，而不是types。 它可以提供信息来知道你的号码是moneyTotal，它告诉我的不仅仅是数据types。
但是，像常用的那样？ 没有。
匈牙利符号为国王时，前缀是VB（和更老！）的日子。 现在不再是这样了，尽pipeC＃ 社区确实要求使用Capital I的前缀作为接口（例如ILoadable ）。
目前的Microsoft准则在这里 。
匈牙利符号不再需要像string示例中那样识别数据types，但是以其他方式识别variables特征仍然很有用。 这里有一篇很好的文章，讨论使用匈牙利符号的有用方法： http : //www.joelonsoftware.com/articles/Wrong.html
这是一个摘录
“在西蒙尼的匈牙利语法中，每个variables都以一个小写标签作为前缀，表示variables所包含的内容。
例如，如果variables名称是rwCol，则rw是前缀。
我在那里故意使用这个词，因为西蒙尼在他的论文中错误地使用了这个词，几代程序员误解了他的意思。
他还使用了一个以“s”或“u”为前缀的string识别是否安全的打印输出的例子，以便像print（uSomeString）; 很容易被认定为错误的。
我对匈牙利符号的大部分观点都提到，现代编辑和IDE完全有能力向您提供关于每个标识符所需的全部信息。 很公平。
但是印刷的代码呢？ 你不是在纸上进行代码审查或演练吗？ 你不使用打印的代码进行培训吗？ 你不使用代码片段的联机帮助吗？ 匈牙利符号在这些场合非常有价值。
我在我所有的代码中都使用（某种）匈牙利符号。 我觉得它缺乏丑陋和缺乏信息。
我个人已经不在了，但是你仍然会争论以范围作为前缀。
我和微软一起去使用他们的大写样式来处理所有的命名约定。 在我看来，整个“class级图书馆开发者devise指南”部分，这个链接是一部分，纯金。
另外，我喜欢Addison Wesley的“框架devise指南”。 它涵盖了所有这些指导方针，包括来自Microsoft团队成员的注释，他们为什么推荐他们提出的build议以及如何在组织内采用。
那么，为了反击，我会说 – 这取决于。 我个人反对他们，但归结于你的团队。 每个小组都应该负责制定他们自己的指导方针。 希望这不包括所谓的匈牙利符号，但它确实应该是一个团队的决定。 你可能会发现你想打破风格指引的情况。
让我对这个问题感到好奇的是，引入前缀（即匈牙利符号）的语言（C和C ++）也是强types的。 就我所知，这一切都是在Pascal在微软使用的情况下完成的。 它似乎也和Mesa一起使用，Mesa是匈牙利人可能对[; <）熟悉的强types语言。
既然如此，那么在这个问题之下进行讨论是公平的，并且考虑：（1）前缀用于解决什么问题;（2）问题是如何消失的？
我知道这不是一个完全的答案，但它可能比一般性反对使用过时或错误的前缀更有用。
即使编译器能够快速而简单地检查variables的types，人类在浏览一段源代码时也无法做到这一点。 因此有些人（比如我）更喜欢使variables名更加冗长，使得它们很快被识别为全局variables或者类variables，string或者整型等等。
它可能不会帮助编译器，但是当阅读一段外部代码时，它肯定节省了你不得不手动查找每个variables。
当然不。 一般来说，我认为这只是噪音。 如果您是独立咨询顾问，或者您的公司没有全面的风格指南， IDesign有很好的指导。 只要看看页面的右侧，你可以D / L他们的C＃编码标准文件的最新迭代。
史蒂夫
我只用它在我的数据库（PostgreSQL）
t_ for table name v_ for view name i_ for index name trig_ for trigger sp_ for stored procedure name p_ for parameter v_ for variable c_ for cursor r_ for record
匈牙利表示法从来不是用来显示variables的数据types。 有人误解说“str”或“i”被用来隐含地定义types。 它只是为了显示“种类”的variables，而不是“types”。
所以要回答这个问题，现在不应该使用，也不应该过去使用。
我知道它已经被链接，但滚动到乔尔的文章的底部获取更多信息 – http://www.joelonsoftware.com/articles/Wrong.html他在哪里谈论匈牙利;
有关良好约定的一般概述，请参阅： http : //msdn.microsoft.com/en-us/library/ms229002.aspx
有一本关于这方面的书来解释每一个公约背后的原因。 很有趣的阅读。
我总是用m_和静态成员variables与s_前缀实例成员variables。 我遇到了MS推荐/不鼓励这种方法的可变文章。
我也很确定，当使用Reflector查看标准.NET库时，我遇到了m_前缀。
不，我们不需要他们。 当我回到过去的时候，我曾经习惯这样做，我们不得不遵循这种编码标准。
此外，随着VS和其他第三方插件（如CodeRush express和Refactor Pro）内置的Intellisense，代码定义窗口和重构工具，没有它的代码工作也变得更加容易。
在代码内部和处理数据types时，我没有理由使用匈牙利符号。
但是当我使用一系列的用户界面控件时，无论是文本框，下拉列表，网格还是其他内容，我都喜欢让我的intellisense为我工作。 所以要做到这一点，我通常使用“uxSomeControlName”作为前缀的控件的id。 这样，当我正在寻找该文本框来获取文本值时，我所要做的就是input“ux”，并显示所有的用户界面ID。 无需searchtxt，ddl，grd或其他任何东西。
现在是正确的，如果你阅读以上，不。 但是当我只需要知道两个字母的时候，我不想坐下来听，试着记住十几个或更多的控制名称。
就像我说的，这只是在前端工作时。
我一直使用它，但这可能是因为我使用Access和Excel的VBA。
对我来说CountAll是一个名字intCountAll是一个名字，它有着不同的名称（它从来没有用于人类的机器），像sintCountAll告诉我它的静态pintCountAll私有和gintCountAll全局，所以我用它的目的; 这是非常有用的。
- 控制名称是一个更安全的，而不是ControlName我有lblControlName，txtControlName，cboControlName，lstControlName等等，所以当我使用VBA我只是键入lst，我有我需要的所有名称，所以我不必记得确切的名称是什么这节省了我很多时间，但是这主要是Access和Excel中的VBA。
问候埃米尔
我会考虑的唯一的前缀是C＃是一个用于成员variables如
public class Test { private int _id; }
我想说的是，现在大多数语言都有一些有限的types – 特别是没有无符号types的概念 – 那么一个命名好的variables就不需要前缀。
在有签名和无符号types的语言或类似的types（如short，int，long或Int8，Int16，In32）中，前缀是有用的，尽pipe别人已经或将会说（他们会，你知道它）。
编译器最好在尝试在expression式中混合不同符号的整数types时发出警告，例如，如果将IDEconfiguration为仅在构build中显示错误（而不是警告）最后的总结（就像你可以用Visual Studio做的那样）。 算术中的混合符号可以严重破坏你的一天，所以你或你的继任者头疼，给他们一个线索。 记住 – 你不是唯一一个会看代码的人。
一个不存在的问题的解决scheme。
虽然今天很多程序员都放弃了，但在某些情况下，我仍然会使用它。 这里是其中的一些;
-
如果你正在维护已经使用它的代码，那么我会继续使用它。
-
当你的公司风格的指导方针仍然需要甚至build议。
-
当你的文档有一个简单的按字母顺序排列的variables列表时，它可以帮助像types一样分组。
我有时使用一种前缀，其中pName是一个参数传入我的函数（注意我不前缀types），oName是本地的我当前的方法，mName是我所在的类的成员和cName是常量或静态只读成员。
我个人觉得它有帮助。
最简洁的答案是不。 但…
我看到远离匈牙利符号的观点，我们商店的标准也是禁止的，但是我仍然发现它在我的一次性或小型实用项目中是有用的，只有一个原因和一个原因：当我编码到大量的网页控制或获胜forms，使用HN使得易于使用Intellisense确保在编码时捕捉每一个控件。
如果我有五个checkbox，他们的名字都是从chk开始的，那么inputchk给我的是他们每个人的名单，我可以很容易地select当前正在工作的那一个。
另外，有时我发现自己在想“那个checkbox又是什么名字？” 而我必须中断并重新查看.ASPX页面。
我已经妥协的一种方法是从HN开始，然后一旦我完成了主要代码的胜利或Webforms，我的最后一步是为HN命名的控件进行全局重命名。 这实际上对我很好。 YMMV，当然。
不，如果你的方法太长，你不能在使用的同时阅读定义，或名称并不意味着这种types，那么你有更严重的devise问题，而不仅仅是命名。
不过，我INSIST，你做他们的types的前缀控制，如txtName。
