C# 为什么我不应该为我的字段添加前缀？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/659552/
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
Why shouldn't I prefix my fields?
提问by Trap
I've never been a fan of Hungarian notation, I've always found it pretty useless unless you're doing some really low level programming, but in every C++ project I've worked on some kind of Hungarian notation policy was enforced, and with it the use of some 'not-really-Hungarian' prefixes as m_ for fields, s_ for statics, g_ for globals and so on.
我从来都不是匈牙利符号的粉丝，我一直觉得它很没用，除非你在做一些非常低级的编程，但在我从事过某种匈牙利符号的每个 C++ 项目中，我都强制执行了某种匈牙利符号策略，并且使用它使用一些“不是真正的匈牙利语”前缀作为 m_ 用于字段，s_ 用于静态，g_ 用于全局等等。
Soon I realized how much useless it was in C# and gradually started to drop all of my old habits... but the 'm_' thing. I still use the m_ prefix on private fields because I really find it very useful to being able to distinguish between parameters, locals and fields.
很快我意识到它在 C# 中是多么无用，并逐渐开始放弃我所有的旧习惯......但是'm_'这个东西。我仍然在私有字段上使用 m_ 前缀，因为我真的发现能够区分参数、局部变量和字段非常有用。
The naming conventions for fields page at MSDNsays I shouldn't, but it does not say why (the way e.g. Google's conventions generally tend to rationalize their prescriptions).
MSDN 上的字段页面的命名约定说我不应该，但它没有说明原因（例如谷歌的约定通常倾向于合理化他们的处方的方式）。
Are there reasons why I shouldn't or is it only a matter of style. If it is the latter, are prefixes generally considered a bad style and can I expect negative reactions from other people working on the codebase?
是否有我不应该这样做的原因，或者这只是风格问题。如果是后者，前缀是否通常被认为是一种糟糕的风格，我可以期待其他从事代码库工作的人的负面反应吗？
采纳答案by Matt Brunell
I like the underbar prefix for member fields. Mostly I like it because that way, all of my member fields are shown alphabetically before my methods in the wizard bar at the top of the screen.
我喜欢成员字段的下划线前缀。大多数情况下我喜欢它，因为这样，我的所有成员字段都按字母顺序显示在屏幕顶部向导栏中的方法之前。
回答by MattJ
When you should:
当你应该：
- When your project coding guidelines say you should
- 当你的项目编码指南说你应该
When you shouldn't:
当你不应该：
- When your project coding guidelines say you shouldn't
- 当你的项目编码指南说你不应该
If you don't have any guidelines yet, you're free to choose whatever you or your team want and feel most comfortable with. Personally when coding C++ I tend to use m_for members, it does help. When coding in other languages, particularly those without true classes (like Javascript, Lua) I don't.
如果您还没有任何指导方针，您可以自由选择您或您的团队想要并感觉最舒服的任何东西。就我个人而言，在编写 C++ 时，我倾向于将其m_用于成员，它确实有帮助。当用其他语言编码时，尤其是那些没有真正类（如 Javascript、Lua）的语言时，我不这样做。
In short I don't believe there is a "right" and a "wrong" way.
简而言之，我不相信有“正确”和“错误”的方式。
回答by Sean
I always prefix member variables with m_and static variables with s_for the same reasons that you state. Some people prefix member variables with an underscore, but I've always found this a bit odd looking (but that's just a personal preference).
出于与您所述相同的原因，我总是在成员变量前加上m_和静态变量前加上s_。有些人用下划线作为成员变量的前缀，但我总是觉得这看起来有点奇怪（但这只是个人喜好）。
Most people I work with use the m_/s_ prefix. I don't really think it matters too much what you use, as long as you're consistent.
与我共事的大多数人都使用 m_/s_ 前缀。我真的不认为你使用什么很重要，只要你是一致的。
回答by Ben S
I try to follow the MSDN .NET library guidelines. They include a naming guidelinessection.
我尝试遵循MSDN .NET 库指南。它们包括命名指南部分。
Obviously, these are secondary to your project guidelines.
显然，这些对于您的项目指南来说是次要的。
回答by Dаn
The auto-implemented property feature in C# 3.0 creates less of a need for this convention one way or the other. Instead of writing
C# 3.0 中自动实现的属性功能以一种或另一种方式减少了对这种约定的需求。而不是写作
string m_name;
public string Name { get { return m_name; } }
or
或者
string _Name;
public string Name { get { return _Name; } }
(or any other convention), you can now write
（或任何其他约定），您现在可以编写
public string Name { get; private set; }
Since you no longer need the explicit backing store variable, you no longer have to come up with a name for it; thus avoiding this entire discussion.
由于您不再需要显式后备存储变量，因此您不再需要为其命名；从而避免整个讨论。
Obviously, this argument doesn't apply when you really need explicit backing store such as to perform validation.
显然，当您确实需要显式后备存储（例如执行验证）时，此参数不适用。
回答by Inferis
I never use them. It encourages sloppy coding. The MSDN coding guidelines, that's where it's at.
我从不使用它们。它鼓励草率的编码。MSDN 编码指南，这就是它所在的位置。
回答by ThorHalvor
what i am used to is that private properties got small underscone f.ex "string _name". the public one got "Name". and the input variables in methods got small letter"void MyMethod(string name)".
我习惯的是私有财产得到了小的underscone f.ex“string _name”。公众号得到了“姓名”。方法中的输入变量有小写字母“void MyMethod(string name)”。
if you got static const is often written with big letters. static const MYCONST = "hmpf".
如果你有静态 const 通常用大字母写。static const MYCONST = "hmpf".
回答by krosenvold
There is one important difference between C++ and C#: Tool support. When you follow the established guidelines (or common variations), you will get a deep level of tool support that C++ never had. Following the standards allows tools to do deeper refactoring/rename operations than you'd otherwise be capable of. Resharper does this. So stick with one of the established standards.
C++ 和 C# 之间有一个重要的区别：工具支持。当您遵循既定的准则（或常见的变体）时，您将获得 C++ 从未有过的深度工具支持。遵循这些标准可以让工具进行更深层次的重构/重命名操作，而不是你无法做到的。Resharper 就是这样做的。所以坚持使用既定标准之一。
回答by argibson
I prefer to mark property backing fields (although as already mentioned .NET 3.0+ reduces the need thanks to Automatic Properties) with underscores but not the "m". For one it puts them at the top of the InteliSense list when I come to use them.
我更喜欢用下划线而不是“m”标记属性支持字段（尽管正如已经提到的 .NET 3.0+ 减少了由于自动属性的需要）。一方面，当我开始使用它们时，它会将它们置于 InteliSense 列表的顶部。
I will admit that I need to brush-up on the guidelines on MSDN, things can change so quickly these days.
我承认我需要复习 MSDN 上的指南，这些天事情变化得如此之快。
回答by rmeador
I never use any hungarian warts whenever I'm given the choice. It's extra typing and doesn't convey any meaningful information. Any good IDE (and I define "good" based on the presence of this feature, among others) will allow you to have different syntax highlighting for static members, instance members, member functions, types, etc. There is no reason to clutter your code with information that can be provided by the IDE. This is a corollary to not cluttering your code with commented-out old code because your versioning system should be responsible for that stuff.
每当我有选择时，我从不使用任何匈牙利疣。这是额外的打字，不会传达任何有意义的信息。任何好的 IDE（我根据此功能的存在定义“好”等等）都将允许您为静态成员、实例成员、成员函数、类型等设置不同的语法高亮显示。没有理由让您的包含可由 IDE 提供的信息的代码。这是一个推论，不要用注释掉的旧代码混淆你的代码，因为你的版本控制系统应该负责那些东西。
回答by rball
With tools like resharper there's really no reason for prefixes. Also if you write short methods, you should be able to tell really quickly where the var is coming from. Finally, I guess I wouldn't really see the need to tell a difference between a static or not because again resharper is going to red line it if you try to do something you're not able to. Even without resharper you're probably saved by the compiler.
使用 resharper 之类的工具，真的没有理由使用前缀。此外，如果您编写简短的方法，您应该能够非常快速地判断 var 的来源。最后，我想我不会真正看到区分静态与否的必要性，因为如果您尝试做一些您无法做到的事情，resharper 会再次将其划红线。即使没有 resharper，您也可能会被编译器保存。
