为什么我不应该为我的字段添加前缀？[关闭]

Question

我从来都不是匈牙利表示法的粉丝，我总是发现它毫无用处，除非你正在做一些非常低级的编程，但在我参与的每个 C++ 项目中，都强制执行了某种匈牙利表示法政策，并且使用一些“不是真正的匈牙利语”前缀，例如 m_ 表示字段、s_ 表示静态、g_ 表示全局等。

很快我就意识到 C# 是多么无用，并逐渐开始放弃我所有的旧习惯......但“m_”的事情。我仍然在私有字段上使用 m_ 前缀，因为我确实发现它对于区分参数、局部变量和字段非常有用。

这 MSDN 中字段页面的命名约定 说我不应该，但它没有说明原因（例如方式谷歌的惯例通常倾向于合理化他们的处方）。

我是否有理由不这样做，或者这只是风格问题。如果是后者，前缀通常被认为是一种不好的风格吗？我可以期待其他从事代码库工作的人做出负面反应吗？

Answer 1

我喜欢构件字段下划线前缀。主要是我喜欢它，因为这样一来，我所有的成员域是按字母顺序之前我在屏幕上方的向导栏显示的方法。

Answer 2

当你应该：

• 时项目编码指南说你应该

当你不应该:

• 时项目编码指南说你不应该

如果你没有任何准则还没有，你可以自由地选择任何你或者你的团队想和感觉最舒服。个人当编码C++我倾向于使用m_成员，它也帮助。当编码在其他语文，特别是那些没有真正的类别(例如Javascript，Lua)我不知道。

在短我不相信有"权利"和一个"错误"的方式。

Answer 3

在C＃3.0的自动实现的属性功能创建更小的需要这一惯例的一种方式或其它。而不是写的

string m_name;
public string Name { get { return m_name; } }

或

string _Name;
public string Name { get { return _Name; } }

（或任何其他约定），你现在可以写

public string Name { get; private set; }

由于不再需要明确的后备存储变量，您不再需要来为它起一个名字;从而避免了整个讨论

显然，这种说法并不适用，当你真的需要明确的后备存储如进行验证。

Answer 4

如一些人所提到的，该MS的准则说：

  

不要使用前缀字段名。   例如，不使用G_或S_到   区分静态与非静态   字段。

我碰巧与此一致。前缀使与无关紧要的字符代码看起来很丑陋和浪费的空间。话虽如此，它往往是共同使用的字段来备份性能，其中外地和属性将具有相同的名称（与私人领域是骆驼和财产是帕斯卡的情况下）。在VB中，这是行不通的，因为VB是不区分大小写。在这种情况下，我建议使用一个_前缀。无多，不会少。它只是看起来更清洁，IMHO。

Answer 5

我已经尝试了M_，S_，只是_，并没有前缀的。我已经在只使用_为所有静态和实例变量解决。我不觉得它重要的是从实例变量区分静态变量。在理论上听起来不错，但实际上它不会产生问题。

一个同事一度取得令人信服的论据，以消除所有的前缀，我们试图在一个项目和它的工作更好，然后我的预期。我带着它期待我的下一个项目，并成为恼火，它“干扰”与智能感知。当你有以下情况

int foo;
public int Foo
{
  get { return foo; }
}

开始输入foo将建议两个实例变量和财产。前缀以下划线变量消除了恼人的双建议，所以切换回仅使用_

Answer 6

我尝试按照 MSDN .NET库准则。它们包括一个命名准则部分。

显然，这些都是次要的项目指南。

Answer 7

我宁愿标记属性支持字段（尽管如已经提到的.NET 3.0+减少了需要由于自动属性）用下划线但不是“M”。对于一个这使他们在智能感知列表的顶部，当我来使用它们。

我承认，我需要刷了MSDN上的准则，事情变化得太快，这些天。

Answer 8

通过像ReSharper的工具，实在没有理由前缀。此外，如果你写简短的方法，你应该能够告诉真的很快，其中VAR是来自。最后，我想我不会真的认为有必要告诉静态或不之间的差异，因为如果你尝试做一些事情再次ReSharper的是要红线是你不能够。即使没有ReSharper的你可能是由编译器保存的。

Answer 9

我总是前缀成员变量与的米_ 并与静态的取值_ 变量，你陈述同样的原因。有些人前缀的成员变量以下划线，但我总觉得这有点奇怪寻找（不过这只是一个个人喜好）。

我使用M_ / S_前缀工作的大多数人。我真的不认为它的事项太多了，你用什么，只要你是一致的。

Answer 10

我从来没有使用它们。它鼓励草率的编码。 在MSDN编码准则，这就是它在

Answer 11

下面是使用_（而不是米_）的几个原因。

（1）许多BCL球员这样做尽管MS的命名指南。 （看看他们的博客。）那些家伙写的框架，因此，他们有一些好习惯值得复制。一些在MSDN上最有用的示例代码是他们写的，所以使用下划线约定。这是一种事实上的行业标准。

（2）以单下划线是通过简单地读取源消除歧义方法和类级别的变量的显着但不显眼的方式。它可以帮助人们了解新（或旧）代码的 在一览的阅读时。是的，你可以将鼠标悬停看到这个在IDE中，但我们不应该被强迫。您可能需要在文本编辑器来阅读，或者我敢说，在纸面上。

（3）有些人说你不需要任何前缀的方法会很短，后来如果需要的话，你可以将字段更改为一个自动实现的属性。但在现实世界中的方法是只要他们需要，并且有字段和属性（例如，串行化和初始化）。

之间的重要差异

脚注：“米”为成员的M_在这里我们使用多余的，但它是小写，因为在许多旧的命名约定的想法之一是该类型的名称开始以大写字母和实例名称开始小写。这并不在.NET应用所以它的双重冗余。还匈牙利表示法有时与旧的C编译器（例如整数或指针铸造和算术），但有用的，即使在C ++使用类处理时，其有用性被削弱。

Answer 12

有是C ++和C＃之间的一个重要的区别：工具支持。当您按照既定的准则（或公共变化），你会得到的工具支持深层次的是C ++从未有过的。继标准允许工具做更深层次的重构/重命名操作比否则你能够。 ReSharper的做到这一点。所以坚持使用的已建立的标准之一。

Answer 13

作为@约翰卡夫提到，没有“正确”的答案。 MattJ是最接近的 - 你应该始终遵循公司的风格指南。在罗马，以及所有

至于我个人的看法，因为它要求在这里，我投你完全放下m_。

相信最好样式是其中所有成员都是PascalCased，无论能见度的（这意味着甚至private成员），和所有参数都camelCased。我不打破这种风格。

我可以理解的前缀属性后备存储字段的愿望;毕竟，你必须在字段和属性，正确区分？我同意，你必须。但使用后的修复。

相反m_MyProperty（或者甚至_MyProperty，我已经看到并在一个时间甚至促进了一次）的

，使用MyPropertyValue。它更容易阅读和理解以及 - 更重要的是 - 这是接近智能感知您的原始属性名。

归根结底，这就是我喜欢一个后缀的原因。如果我想使用智能感知您访问MyPropertyValue（典型值）输入“My <down-arrow> <tab>”，因为那时你足够近，只有MyProperty和MyPropertyValue均榜上有名。如果你想使用智能感知访问m_MyProperty，你必须输入“m_My <tab>”。

这是关于按键经济，在我看来。

Answer 14

我从来没有做到这一点，为什么是我[试图]让我的方法很短。如果我能在屏幕上看到整个方法，我可以看到参数，可以，我可以看到当地人，所以我可以告诉什么是阶级所拥有的，什么是设置了一个param或本地。

我通常我的名字未参数和使用特定的符号本地人，但并非总是如此。我什么，如果不是矛盾。我靠，事实证明我的方法很短，尽量保持他们这样做X，Y和Z时，他们只应做X。

总之，这是我的两分钱。

Answer 15

除非我坚持用vi或Emacs编辑代码，我的IDE会成员的差异显示了我，所以我很少使用任何特殊的约定。这也无二前缀与I类或接口以C

有人请解释在接口I-前缀的.NET风格。 ：）

Answer 16

我所用的是私有财产得到了小underscone f.ex“字符串_name”。公众一个有“名”。和在方法中的输入变量有小字母“空隙的MyMethod（字符串名称）”。

如果你有静态常量常常写有大字。 static const MYCONST = "hmpf"。

Answer 17

我从来没有使用任何匈牙利疣每当我给出的选择。这是额外的输入，并没有传达任何有意义的信息。任何一个优秀的IDE（我定义的“好”的基础上这一功能的存在，等等）可以让你有不同的语法高亮显示静态成员，实例成员，成员函数，类型等没有理由打乱您与信息码能够由IDE来提供。这是一个必然结果不注释掉旧代码弄乱你的代码，因为你的版本系统应负责的东西。

Answer 18

在最好的办法是与你的同事一个标准达成一致，并坚持下去。它没有绝对必须，将工作最适合每个人，只是一个方法达成一致，更重要的比方法，你居然同意的方法。

我们选择了我们的代码标准是使用_作为前缀的成员变量。其中一个原因是，它可以很容易地找到局部变量的智能感知。

我们商定了标准之前，我用另一个。我没有使用任何前缀在所有，并且写this.memberVariable在代码来显示，我用一个成员变量。

使用在C＃3的属性的简写，我发现我使用少了很多明确的成员变量。

Answer 19

在最接近官方指南是了StyleCop ，微软的工具，它可以自动分析源文件和检测从所述推荐的编码样式违反，并且可以从Visual Studio内运行和/或自动化的构建如MSBuild的。

我们用它在我们的项目和它确实有助于使代码样式和布局开发商之间更加一致，虽然被警告它确实需要的非常的有点习惯了！

要回答你的问题 - 它不允许任何匈牙利命名法，也不像m_任何前缀（事实上，它不允许在所有使用下划线）

Answer 20

我不使用该样式的任何更长的时间。它的开发是为了帮助您快速了解如何使用变量。较新的开发环境，让你看到通过在变量悬停鼠标的信息。如果你使用这些较新的工具的必要性已经消失。

Answer 21

有可能也有一些见解从 C ++编码标准中收集（的萨特，药草和<强> Alexandrescum安德烈下，2004）。项目＃0的标题是“不要为鸡毛蒜皮的事（或：知道什么是不规范）。”

他们说：“如果你不能在自己的命名惯例决定，尝试...私有成员变量 likeThis _ ...”（记住使用的触摸这个具体问题一点点前导下划线是受试者在C非常具体的规则++）。

然而，到那里之前，他们强调的一致性，一定程度“......最重要的是没有设置的规则，但是，只要有风格一致已经在文件中使用......”

Answer 22

在C / C ++是符号的好处是更容易地看到一个符号的类型是不必去寻找报关。这些样式智能感知到来之前出现了，“转到定义” - 我们经常去鹅追逐寻找谁知道有多少头文件的声明。在一个大项目做使用混合装配+源代码和原始调用堆栈取证时，这可能会在看C源代码的时候是一个显著的烦恼这已经够糟糕的，但更糟。

在面对这些现实，利用M_和所有其他的匈牙利规则开始制作某种意义上甚至因为看着不熟悉的代码时，它会节省多少时间只是找了一个符号的类型的维护开销。当然，现在我们有智能感知和“转到定义”，所以保存该命名约定的动机主要时间不再存在。我不认为有做任何更多的远点，我一般尽量使用.NET库的准则去只是为了保持一致，并可能获得更多一点的工具支持。

Answer 23

我确信我会因此而受到批评，但就这样吧。

它被称为 Microsoft 的 .NET 库指南，但它实际上是 布拉德·艾布拉姆斯 意见 (文档在这里) - 还有其他有正当理由的观点。

人们倾向于追随大多数人的观点，而不是对特定的风格有充分的理由。

重要的一点是评估为什么使用某种特定风格以及为什么它比另一种风格更受青睐 - 换句话说，有一个选择一种风格的理由，而不仅仅是因为每个人都说这是应该做的 - 自己思考。

不使用旧式匈牙利语的基本原因是使用缩写，每个团队都不同并且难以学习 - 这很容易通过不缩写来解决。

随着可用的开发工具的变化，样式应该更改为最有意义的样式 - 但每个样式项都有充分的理由。

以下是我的风格指南和我的理由 - 我一直在寻找改进我的风格的方法，以创建更可靠且更易于维护的代码。

变量命名约定

我们对变量命名约定都有自己的看法。有许多不同的样式将有助于生成易于维护的高质量代码 - 任何支持有关变量的基本基本信息的样式都可以。特定命名约定的标准应该是它有助于生成可靠且易于维护的代码。不应使用的标准是：这是丑陋的微软（即Brad Abrams）表示不要使用这种风格 - Microsoft 并不总是生成最可靠的代码，只需查看 Expression Blend 中的错误即可。在阅读代码时，变量名应该立即传达有关该变量的三个基本事实，这一点非常重要：它的范围是类型A清楚地了解其用于范围的内容：Microsoft 建议完全依赖 IntelliSense。IntelliSense 非常棒；然而，人们根本不会将鼠标悬停在每个变量上来查看它的范围和类型。假设变量位于其不在的范围内可能会导致严重错误。例如，如果将引用变量作为参数传入，并且在本地范围内更改它，则在方法返回后，更改将保留，这可能是不希望的。如果在局部范围内修改字段或静态变量，但人们认为它是局部变量，则可能会导致意外行为。因此，能够仅查看变量（而不是将鼠标悬停在其上）并立即知道其范围非常重要。

建议使用以下样式来指示范围；但是，任何样式都可以，只要它能够清楚且一致地指示变量的范围即可：M_字段变量P_参数传递到方法S_静态变量本地变量类型：如果人们认为自己正在使用一种特定类型，而实际上却在使用另一种类型，则可能会发生严重错误 - 同样，我们只是简单地将鼠标悬停在每个变量上来确定其类型，我们只是假设我们知道它的类型是什么，并且这就是错误产生的方式。

缩写：缩写是邪恶的，因为它们对于不同的开发人员来说可能意味着不同的东西。一位开发人员可能认为前导小写“s”表示字符串，而另一位开发人员可能认为它表示带符号整数。缩写是懒惰编码的标志——多花一点时间输入全名，让开发人员清楚必须维护代码。例如，“str”和“string”之间的区别只有三个字符——不需要花费更多的努力就可以使代码易于维护。

仅内置数据类型的常见且清晰的缩写是可接受的，但必须在团队内标准化。

自记录代码：为变量名称添加清晰的描述可以让其他开发人员非常轻松地阅读和理解代码 - 使名称易于理解，以便团队经理即使不是开发人员也可以阅读和理解代码。

变量名称部分的顺序：推荐的顺序是范围-类型-描述，因为：IntelliSense将对所有类似的示波器进行分组，并且在每个范围内IntelliSense将对所有类似的类型进行分组，这使查找变得容易 - 尝试以另一种方式找到变量，使其非常容易看到和理解范围，并看到和理解它是相当常见的类型风格易于理解，它将通过FXCOP

例子：这里有一些例子：m_stringcustomername p_stringcustomerdatabaseconnectionstring intnumberofcustomerrecords或inumberofcustomerrecords或integernumberofcustomerrecords这些简单规则将显着提高代码可靠性和可维护性。

控制结构单行语句所有控制结构（如果，何时，for等）应始终用牙套包裹，因为添加一个新的语句非常容易，而不是意识到给定语句属于控制结构打破代码逻辑而不生成任何编译时间错误。

方法异常包装所有方法都应该用一个外部 try-catch 来包装，该陷阱提供一个恢复、识别、定位、记录并决定是否抛出的位置。意外的异常导致我们的应用程序崩溃 - 通过包装捕获所有未处理异常的每个方法，我们保证识别和记录所有异常，并防止我们的应用程序崩溃。这需要更多的工作，但结果是值得付出努力的。

缩进缩进不是主要问题；但是，建议使用四个空格且不使用制表符。如果打印代码，第一个打印机选项卡通常默认为 8 个空格。不同的开发人员倾向于使用不同的选项卡大小。Microsoft 的代码通常缩进 4 个空格，因此如果使用任何 Microsoft 代码并使用 4 个空格以外的空间，则需要重新格式化该代码。四个空格使其变得简单且一致。

Answer 24

如果你没有一个特定的思想指导下编码，你应该继续使用您的实际M_符号和改变它，如果该项目的编码准则是这么说的。

Answer 25

是的功能。

• 不使用全球变量。
• 不用静态变量。
• 不要使用的部件的变量。

如果你真的要，但只有当你真的拥有、使用唯一一个变量来访问您的应用程序/环境。