是否真的有必要的前缀（“匈牙利表示法”）？

Question

由于C＃是强类型的，我们真的需要为变量添加前缀吗？

e.g。

iUserAge
iCounter
strUsername

我过去常用前缀，但是未来我看不到任何好处。

Answer 1

  

可变前缀（匈牙利语）真的有必要吗？

NO！

事实上，微软自己的style guidelines（这种做法起源于此）现在建议反对它。特别是，请参阅General Naming Conventions部分，其中包括以下文字（粗体字，不少）：

  

请勿使用匈牙利表示法。

Answer 2

我认为唯一适合弯曲标准和前缀变量的地方：

• 控制名称：txtWhatever - 我发现我不是唯一的一个。好处是你可以在txtName旁边找到像lblName这样的东西，你不需要进入NameLabel / NameTextBox方向。

• 类成员变量：_whatever。我已经尝试了m_和没有前缀，结果是简单的下划线。 m_更难以打字，并且没有前缀有时会变得混乱（特别是在维护期间，我知道你们所有人在编写代码时都会知道他们的代码）

我没有找到任何一致的情况，其中为变量添加其类型前缀会使代码更具可读性。

编辑：我确实阅读了Microsoft指南。但是我认为在适当的情况下允许编码样式发展和/或“弯曲”。正如我上面提到的，我发现使用下划线前缀对试验和错误有用，并且肯定比使用它更好。无论代码中的任何地方。

支持“不断发展”的理论 - 回到.NET 1.x，当微软发布编码指南时，他们建议使用Camel套管来处理所有事情，甚至是常量。我现在看到他们已经改变并建议使用Pascal案例用于常量或公共只读字段。

此外，即使.NET Framework类库目前还充满了m_和_和s_（尝试使用Reflector浏览实现）。毕竟，只要在整个项目中保持一致性，就由开发人员决定。

Answer 3

如果匈牙利语的意思是“带有类型缩写的前缀”，例如uCount或pchzName，那么我会说这种做法很糟糕，幸好似乎正在逐渐淡化。

但是，我仍然认为前缀对范围非常有用。在我的工作室，我们使用此约定为变量添加前缀：

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参数前缀是有用的。在函数内部，您可以随时了解var的来源。通常，当我们想要修改或更改其含义时，我们会将var复制到另一个。

简而言之：现代工具不需要类型的前缀。 IDE负责为您识别和检查这些内容。但基于范围的前缀对于可读性和清晰度非常有用。

还有像Intellisense一样有趣的附带好处。您可以输入i_ ctrl-space并获取func的所有输入参数以供选择。或者g_ ctrl-space来获取你所有的单身人士。这是一个节省时间。

Answer 4

不。我们ever需要吗？

Answer 5

匈牙利表示法很难看。唯一的例外是接口，大多数人认为它是可以接受的。

Linus总结得很好： “将函数类型编码到名称中（所谓的匈牙利表示法）是脑损坏的 - 编译器无论如何都知道类型并且可以检查它们，它只会让程序员感到困惑”

Answer 6

没有。 Hungarian Notation只会给代码增加不必要的噪音，并且在编译器类型检查方面是多余的。

Answer 7

是的，如果匈牙利语符号按照原来的意思使用，而不是由Microsoft实施。与上面的示例非常相似，它将文本框和相应的标签显示为lblWhatever，txtWhatever。用它来定义变量的使用，而不是类型。它可以提供信息，知道您的号码是moneyTotal，这不仅告诉我数据类型。

但是，如常用？否。

Answer 8

我看到针对匈牙利符号的大多数论点都提到现代编辑器和IDE完全能够为您提供有关每个标识符所需的所有信息。很公平。

但是印刷代码怎么样？你不是在纸上进行代码审查或演练吗？您是否不将印刷代码用于培训目的？你不是使用代码片段进行在线帮助吗？在这些场合，匈牙利语符号非常非常有价值。

我在所有代码中都使用（某种）匈牙利符号。我发现它缺乏丑陋而缺乏信息。

Answer 9

不再需要匈牙利表示法来识别数据类型中的数据类型，但它仍然可用于以其他方式识别变量的特征。这是一篇很好的文章，讨论了使用匈牙利符号的有用方法：http://www.joelonsoftware.com/articles/Wrong.html

这是一段摘录

“在Simonyi的匈牙利表示法版本中，每个变量都以小写标签为前缀，表示变量所包含的内容。

例如，如果变量名称是rwCol，则rw是前缀。

我正在故意使用“善意”一词，因为西蒙尼错误地在他的论文中使用了这个词，而且几代程序员误解了他的意思。“

他还使用了一个识别前缀为's'或'u'的字符串的示例，以确定它们是否可以安全打印出来，以便像print（uSomeString）这样的语句;很容易被认定为错误。

Answer 10

前缀是Hungarian Notation为王时的VB（以及更早！）的剩余时间。情况已经不是这样了，尽管C＃community does mandate就像使用大写I的前缀作为接口（例如ILoadable）。

当前的Microsoft指南为here。

Answer 11

嗯，反对，我会说 - 这取决于。我个人反对他们，但这取决于你的团队。每个团队都应负责制定自己的指导方针。希望这不包括所谓的匈牙利表示法，但它确实应该是一个团队决策。您可能会发现需要打破样式准则的情况。

Answer 12

让我对这个问题充满好奇的是，引入前缀（即匈牙利符号）的语言（C语言C ++）也是强类型的。据我所知，这一切都是通过Pascal在微软的使用完成的。它似乎也与Mesa一起使用，这是一种强类型语言，匈牙利人可能对[;＆lt;）有一定的了解。

在这种情况下，公平地解决问题并考虑（1）用什么问题来帮助解决问题，以及（2）问题是如何消失的？

我知道这不是一个答案，但它可能比使用前缀过时或错误的一揽子反对更有用。

Answer 13

我个人现在不再这样了，但你仍然会争辩说明范围的前缀。

我选择使用Microsoft并将Capitalization Styles用于所有命名约定。在我看来，整个“类库开发人员的设计指南”部分是该链接的一部分，是纯金。

此外，我喜欢Addison Wesley的“框架设计指南”一书。它涵盖了所有这些指南，并附有Microsoft团队成员的注释，以及他们为什么建议他们提出的建议以及如何在组织内部采用它。

Answer 14

绝对不是。作为一般规则，我开始相信它只是噪音。如果您是独立顾问或您的公司没有全面的风格指南，IDesign有一个很好的指南。只需查看页面的右侧，您就可以对其C＃编码标准文档的最新版本进行D / L。

史蒂夫

Answer 15

我只在我的数据库中使用它（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

Answer 16

匈牙利表示法从未用于显示变量的数据类型。被误解为暗示“str”或“i”用于隐式定义类型。它只是为了显示变量的“种类”，而不是“类型”。

所以回答这个问题，它现在不应该使用，也不应该在过去使用过。

我知道它已被链接，但滚动到Joel文章的底部以获取更多信息 - http://www.joelonsoftware.com/articles/Wrong.html他在哪里谈论匈牙利语

Answer 17

即使编译器可以快速轻松地检查变量的类型，但人们在浏览一段源代码时无法这样做。 因此，有些人（像我一样）更喜欢使变量名称更加冗长，使得它们可以快速识别为全局或类变量，字符串或int等。

它可能对编译器没有帮助，但是当读取外部代码时，它确实可以节省您必须手动查找每个变量...

Answer 18

我总是在实例成员变量前加上 m __ ，使用 s _ 加上静态成员变量。我遇到了MS推荐/阻止这种方法的变量文章。

我很确定在使用Reflector查看标准.NET库时，我遇到了 m _ 前缀...

Answer 19

有关良好惯例的一般概述，请参见此处： http://msdn.microsoft.com/en-us/library/ms229002.aspx

有一本关于这一点的书，他们解释了每个公约背后的原因。非常有趣的阅读。

Answer 20

不，我们不需要它们。在过去的日子里，我常常遵循这一点，我们被迫遵循这种编码标准。

使用Intellisense，代码定义窗口和重构工具内置到VS和其他第三方插件（如CodeRush express和Refactor Pro）中，没有它就可以更轻松地处理代码。

Answer 21

在代码内部和处理数据类型时，我认为没有理由使用匈牙利表示法。

但是当我使用一系列用户界面控件时，无论是文本框，下拉列表，网格还是什么都没有，我希望我的intellisense能为我工作。所以为了实现这一点，我通常使用前缀“uxSomeControlName”来创建控件的id。这样，当我正在寻找该文本框来获取它的文本值时，我所要做的就是键入“ux”并显示所有用户界面ID。无需搜索txt，ddl，grd或其他任何内容。

现在这是正确的，如果您阅读上述内容，请参阅。但是，当我只需要知道两个字母时，我不想坐下来试着记住十几个控制名称。

就像我说的那样，这只是在前端工作时。

Answer 22

我一直都在使用它，但这可能因为我使用VBA和Access和Excel。

对我来说，CountAll是一个名称intCountAll是一个具有这种差异的名称，它额外地描述了名称（从不用于仅供人类使用的机器），例如sintCountAll告诉我它的静态pintCountAll private和gintCountAll全局因此我使用它的目的;它非常有用。

• 控制名称更安全，而不是ControlName我有lblControlName，txtControlName，cboControlName，lstControlName等所以当我使用VBA时我只需输入lst并且我拥有我需要的所有名称所以我不必记住什么是确切的名称可以节省我很多时间，但这主要是Access和Excel中的VBA。

此致 埃米尔

Answer 23

解决不存在的问题。

Answer 24

虽然今天许多程序员都在放弃它，但在某些情况下我仍会使用它。以下是其中一些;

• 如果您要维护代码 已经使用它，然后我会保留 使用它。

• 当您的公司风格指引     仍需要甚至建议。

• 当您的文档很简单时     按字母数字排序的列表     变量，它有助于组合类型。

Answer 25

我考虑用于C＃的唯一前缀是_用于成员变量，例如

public class Test
{
    private int _id;
}

Answer 26

我有时使用一种前缀，其中pName是传递给我的函数的参数（注意我没有为类型添加前缀），oName是我当前方法的本地，mName是我所在的类的成员， cName是常量或静态只读成员。

我个人认为这有帮助。

Answer 27

我想说现在大多数语言都有一组有限的类型 - 特别是没有无符号类型的概念 - 那么一个命名良好的变量不应该需要前缀。

在具有签名和无符号类型的语言或一系列类似的类型（例如，short，int，long或Int8，Int16，In32）中，前缀是有用的，尽管其他人已经或将会说（并且他们将，你知道吗。

当您尝试在表达式中混合使用不同符号的整数类型时，编译器最多会发出警告，例如，如果您将IDE配置为仅显示错误（而不是警告），则很容易错过最终摘要中的构建（与Visual Studio一样）。混合运算中的符号会严重破坏你的一天，所以让你或你的继任者头疼并给他们一些线索。记住 - 你不是唯一一个会看到代码的人。

Answer 28

简短的回答是否定的。但...

我看到了摆脱匈牙利符号的意义，我们商店的标准也禁止它，但我仍然觉得它在我的一次性或小型实用项目中有用只有一个原因和一个原因：当我使用HN编码到web或win形式的大量控件，使其易于使用Intellisense确保我在编码时捕获每个控件。

如果我有一个五个复选框，并且他们的名字都以chk开头，那么输入chk会给我列出每个复选框，我可以很容易地选择那一个我正在处理的那个。

另外，有时候我发现自己想知道“那个复选框再次命名的是什么？”我必须中断并再次查看.ASPX页面。

我已经妥协的一种方式是从HN开始，然后一旦我完成了win或web形式的主代码，我的最后一步是为HN命名的控件进行全局重命名。这实际上对我来说效果很好。当然是YMMV。

Answer 29

不，如果您的方法太长，以至于您无法在使用的同时阅读定义，或者名称并不意味着类型，那么您的设计问题会比命名更严重。

但是，我INSIST你用它们的类型作为前缀控件，比如txtName。