39

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

例如

iUserAge
iCounter
strUsername

我过去常常加前缀，但以后我看不到任何好处。

4

29 回答 29

49

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

不！

事实上，微软自己的风格指南（实践起源）现在反对它。特别是，请参阅通用命名约定部分，其中包括以下文本（粗体，不少于）：

不要使用匈牙利符号。

当然，这些指南在 Microsoft 之外不具有约束力或强制性。然而，这是平台供应商发布的建议，它不仅仅是从任何先前的指南中删除积极的建议，而是今天的措辞强硬和强调的消极建议。

换句话说，不要再使用它们了。

于 2008-11-21T16:03:04.543 回答
30

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

  • 控制名称：txtWhatever- 我知道我不是唯一一个。好消息是你可以在 txtName 旁边想出 lblName 之类的东西，而且你不需要进入 NameLabel/NameTextBox 方向。

  • 类成员变量：_whatever. 我已经尝试了 m_ 并且根本没有前缀，最后得到了简单的下划线。m_ 更难输入，没有前缀有时会让人感到困惑（尤其是在维护期间，我知道你们所有人在编写代码时都熟记于心）

不过，我没有发现任何一致的情况，在变量前面加上它的类型会使代码更具可读性。

编辑：我确实阅读了 Microsoft 指南。但是，我认为编码风格可以在适当的情况下发展和/或“弯曲”。正如我上面提到的，我发现在反复试验中使用下划线前缀很有用，而且肯定比在代码中的任何地方都使用 this.whatever 更好。

支持“进化”理论——早在 .NET 1.x 中，当微软发布编码指南时，他们建议对所有内容使用 Camel 大小写，甚至是常量。我现在看到他们已经改变并建议将 Pascal case 用于常量或公共只读字段。

此外，即使是 .NET Framework 类库目前也充满了 m_ 和 _ 和 s_（尝试使用反射器浏览实现）。所以毕竟，这取决于开发人员，只要在您的项目中保持一致性。

于 2008-11-21T16:11:05.367 回答
22

如果匈牙利语的意思是“带有类型缩写的前缀”，例如 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 获取所有单身人士。这是一个节省时间的方法。

于 2008-11-21T19:02:58.047 回答
9

没有。我们曾经需要吗？

于 2008-11-21T16:01:07.447 回答
8

匈牙利符号很丑陋。唯一的例外是接口，大多数人认为它是可以接受的。

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

于 2008-11-21T16:02:20.907 回答
6

不，匈牙利表示法只是给代码增加了不必要的噪音，并且对于编译器类型检查来说是多余的。

于 2008-11-21T16:01:14.827 回答
5

是的，如果按照最初的意思使用匈牙利符号，而不是按照 Microsoft 实现的那样使用。很像上面的例子，它将文本框和相应的标签显示为 lblWhatever、txtWhatever。用它来定义变量的用途，而不是类型。它可以提供信息来知道你的号码是moneyTotal，它告诉我的不仅仅是数据类型。

但是，像常用的那样吗？不。

于 2008-11-21T18:29:01.627 回答
4

前缀是 VB（和更早的！）时代​​的遗留物，当时匈牙利符号为王。情况已不再如此，尽管 C#社区确实强制要求为接口使用 Capital 前缀I（例如ILoadable）。

当前的 Microsoft 指南在此处。

于 2008-11-21T16:02:38.740 回答
4

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

这是摘录

“在 Simonyi 的匈牙利符号版本中，每个变量都带有一个小写标签前缀，表示该变量所包含的东西的种类。

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

我是故意用类型这个词的，因为西蒙尼在他的论文中错误地使用了类型这个词，而一代又一代的程序员误解了他的意思。”

他还使用了一个示例来识别前缀为“s”或“u”的字符串，以识别它们是否可以安全打印出来，例如 print(uSomeString); 之类的语句。很容易被识别为错误的。

于 2008-11-21T19:17:49.360 回答
4

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

但是打印代码呢？你不会在纸上进行代码审查或演练吗？您不将打印代码用于培训目的吗？您不使用代码片段来获取在线帮助吗？匈牙利符号在这些场合非常有价值。

我一直在我的所有代码中使用（某种）匈牙利符号。我发现它的缺席很丑陋，而且缺乏信息。

于 2009-11-17T23:32:55.957 回答
3

我个人不再这样做了，但是您仍然会有人争论为范围添加前缀。

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

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

于 2008-11-21T16:04:47.160 回答
3

好吧，为了反驳，我会说 - 这取决于。我个人反对他们，但这取决于你的团队。每个团队都应负责制定自己的一套指南。希望这不包括所谓的匈牙利符号，但它确实应该是一个团队的决定。您可能会发现想要打破风格准则的情况。

于 2008-11-21T16:05:51.057 回答
3

让我对这个问题感到好奇的是，引入前缀（即匈牙利符号）的语言（C 然后是 C++）也是强类型的。据我所知，Pascal 在 Microsoft 的使用也是如此。而且它似乎也与 Mesa 一起使用，这是一种强类型语言，匈牙利人可能对 [;<) 有一定的了解。

在这种情况下，从问题的角度出发并考虑（1）什么问题被用来帮助解决问题以及（2）这个问题是如何消失的，这是公平的。

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

于 2008-11-21T21:24:01.087 回答
2

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

它可能对编译器没有帮助，但是当读取一段外国代码时，它肯定会节省您手动查找每个变量的时间......

于 2008-11-21T16:05:27.453 回答
2

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

史蒂夫

于 2008-11-21T18:56:57.983 回答
2

匈牙利符号从来都不是用来显示变量是什么数据类型的。建议使用“str”或“i”来隐式定义类型是被误解的。这意味着只显示变量的“种类”，而不是“类型”。

因此，要回答这个问题，现在不应该使用它，过去也不应该使用它。

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

于 2009-05-26T20:11:02.960 回答
2

我只在我的数据库（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
于 2009-05-06T20:23:43.217 回答
1

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

有一本关于这方面的书，他们在其中解释了每个约定背后的原因。读起来很有趣。

于 2008-11-21T16:05:11.510 回答
1

不，我们不需要它们。我过去常常遵循这一点，我们被迫遵循那种编码标准。

此外，借助内置于 VS 和其他第三方插件（如 CodeRush express 和 Refactor Pro）中的 Intellisense、代码定义窗口和重构工具，在没有它的情况下使用代码会更容易。

于 2008-11-21T19:22:23.843 回答
1

我总是在实例成员变量前面加上m__和在静态成员变量前面加上s_。我遇到了来自推荐/反对这种方法的 MS 人员的可变文章。

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

于 2008-11-21T16:26:51.700 回答
1

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

但是当我使用一系列用户界面控件时，无论它们是文本框、下拉列表、网格还是其他什么，我都喜欢让我的智能感知为我工作。因此，为了实现这一点，我通常使用前缀“uxSomeControlName”来制作控件的 ID。这样，当我在寻找那个文本框来获取它的文本值时，我所要做的就是输入“ux”并显示所有用户界面 ID。无需搜索 txt、ddl、grd 或其他任何内容。

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

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

于 2008-11-21T20:24:54.577 回答
1

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

对我来说 CountAll 是一个名字 intCountAll 是一个有这个区别的名字，它额外描述了这个名字（从来没有打算为机器只用于人类），比如 sintCountAll 告诉我它的静态 pintCountAll 私有和 gintCountAll 全局所以为了我使用它的目的；它非常有用。

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

问候埃米尔

于 2009-08-17T08:17:14.827 回答
0

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

public class Test
{
    private int _id;
}
于 2008-11-21T16:04:42.370 回答
0

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

在具有有符号和无符号类型的语言中，或大量类似类型（例如，short、int、long 或 Int8、Int16、In32）中，前缀是有用的，尽管其他人已经或将要说什么（他们会，你知道它）。

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

于 2008-11-21T16:09:58.943 回答
0

一个不存在的问题的解决方案。

于 2008-11-21T17:50:39.957 回答
0

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

  • 如果您正在维护已经使用它的代码，那么我会继续使用它。

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

  • 当您的文档有一个简单的按字母数字排序的变量列表时，它有助于对类似类型进行分组。

于 2008-11-21T18:39:55.410 回答
0

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

我个人觉得它有帮助。

于 2008-11-21T20:35:03.777 回答
0

最简洁的答案是不。但...

我看到了摆脱匈牙利符号的意义，我们商店的标准也禁止它，但我仍然发现它在我的一次性或小型实用程序项目中很有用，原因只有一个：当我编码到一个Web 或 win 表单中的大量控件，使用 HN 可以轻松使用 Intellisense 确保我在编码时捕获每个控件。

如果我有五个复选框，并且它们的名称都以 chk 开头，那么输入 chk 会给我每个复选框的列表，我可以轻松地选择我正在处理的那个。

另外，有时我发现自己想知道“那个复选框又叫什么名字了？” 我不得不中断并再次查看 .ASPX 页面。

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

于 2009-05-06T20:37:06.837 回答
-1

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

但是，我坚持要使用它们的类型为控件添加前缀，例如 txtName。

于 2008-11-21T16:03:26.337 回答