我从来不喜欢匈牙利命名法，除非你在做一些非常底层的编程，否则我一直觉得它没什么用，但在我参与的每个C++项目中都执行了某种形式的匈牙利命名策略，其中包括使用一些“不是真正的匈牙利命名法”前缀，例如m_表示字段，s_表示静态，g_表示全局等。
后来我意识到在C#中它有多么无用，并逐渐放弃了所有旧习惯... 但是'm_' 还在使用。 我仍然在私有字段上使用 m_ 前缀，因为我真的发现这非常有用，可以区分参数、本地变量和字段。
MSDN上的字段命名约定页面说我不应该这样做，但没有说明为什么（例如Google的约定通常倾向于理性化他们的规定方式）。
是否有不允许我这样做的原因，还是只是一个风格问题？如果是后者，那么前缀通常被认为是一种不良风格吗？我能否期望其他人在工作中对代码库作出负面反应？
我喜欢在成员字段前面添加下划线前缀。主要是因为这样，所有的成员字段都会在屏幕顶部的向导栏中按字母顺序显示在我的方法之前。
何时应该使用：
何时不应该使用：
如果您还没有任何指南，您可以选择您或您的团队认为最舒适的任何方式。个人在编写C++代码时倾向于使用 m_ 作为成员变量前缀，这确实有所帮助。但在使用其他语言（尤其是那些没有真正类的语言，如Javascript、Lua）时则不使用。
简而言之，我认为并不存在“正确”或“错误”的方法。
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; }
由于你不再需要显式的后备存储变量，因此你不再需要为其命名；从而避免了整个讨论。
显然，在你真正需要显式后备存储时（例如执行验证），这个论点就不适用了。
我曾经尝试使用m_、s_、just _以及没有前缀来命名变量。最终我选择了只使用下划线(_)来命名所有的静态和实例变量。我认为将静态变量与实例变量区分开来并不重要。从理论上讲，这听起来很好，但在实践中并不会产生问题。
有一次我的一个同事提出了一种有说服力的观点，即取消所有前缀。我们在一个项目上尝试了一下，效果超出我的预期。于是我把这种方式应用到了下一个项目中，但很快就因为它“干扰”了智能感知而感到烦恼。当你遇到以下情况时：
int foo;
public int Foo
{
get { return foo; }
}
输入“foo”时将会出现实例变量和属性两种建议。在变量前加下划线可以消除烦人的双重建议，所以我又回到了只使用下划线的方式。
正如一些人所提到的，微软指南中说：
不要为字段名使用前缀。 例如，不要使用 g_ 或 s_ 来区分静态和非静态字段。
我同意这个观点。前缀会让你的代码变得丑陋，并浪费空间来放置无关紧要的字符。尽管如此，通常使用字段作为属性的后备存储，而字段和属性的名称相同（私有字段为驼峰式，属性为帕斯卡式）。在 VB 中，这种情况行不通，因为 VB 不区分大小写。在这种情况下，我建议使用单个 _ 前缀，既不多也不少。在我看来，这样看起来更干净。
我尝试遵循MSDN .NET库指南，其中包括一个命名指南部分。
显然，这些对于您的项目指南来说是次要的。
我喜欢在属性的后备字段上打标记（尽管如已提到的，由于自动属性.NET 3.0+减少了这种需要），但不使用“m”作为前缀。首先，这将使它们出现在InteliSense列表的顶部，当我需要使用它们时。
我承认我需要重新查看MSDN的指南，因为这些内容在这些天里变化得如此之快。
有了像resharper这样的工具，就没有必要使用前缀。如果您编写短方法，您应该能够很快地确定变量来自哪里。最后，我认为没有必要区分静态还是非静态，因为再次使用resharper将在您尝试执行无法执行的操作时将其标记为红线。即使没有resharper，您也可能会受到编译器的保护。
我总是在成员变量前加上m_，在静态变量前加上s_，原因与你所说的相同。有些人用下划线作为成员变量的前缀，但我一直觉得这看起来有点奇怪（但这只是个人偏好）。
我和大多数合作的人都使用m_/s_前缀。我认为重要的是保持一致，不管你使用什么。
_ 被用作换行转义字符）。 - Christian Klauser我从不使用它们。这会鼓励粗心编码。 MSDN编码指南才是王道。