我知道这个问题已经被问了一下，从它的外观来看，这个问题没有明确的是或否答案，但是，我仍然对某些事情感到困惑。
通常在我编程时，我会遵循一些关于前缀的规则：
我现在有一份新工作，我注意到代码中没有使用前缀。我问为什么，他们回答说IDE完成了跟踪成员变量是什么以及什么是局部变量的所有工作。现在我在想，可能是这样，但不管怎么说使用前缀不是更容易吗？
我的意思是，如果我有一个成员，一个名为“robot”的静态变量和一个局部变量，那么在编写方法时引用它是不是很麻烦？这可能是一个不切实际的例子，但我喜欢在我脑海中设置一个良好的规则集，即使是在不切实际的情况下，我也可以始终如一地应用。
这个例子是否可以证明使用匈牙利符号？
我想我会制作一个优点/缺点列表并在我了解更多信息时进行编辑。
反对匈牙利语的争论：
Class.Robot或Robot
this.robot
robot
不需要匈牙利人。
计数器：
仍然存在不一致性，机器人在不同的方法中可能意味着不同的东西。为了保持一致，你应该在每个Robot变量之前为Class或this（或没有）添加前缀。
最重要的是，假设你想要访问静态变量Strawberry，你怎么知道名为Strawberry的成员变量没有定义？也许它是在另一个你看不到的文件中定义的，所以你可能会得到意想不到的结果。现在您可能会说这是通过IDE可见的，但我认为使用前缀是优越的，因为您看到了您正在引用的内容，而您可能会错过IDE告诉您的内容。当然，您也可以使用此/ Classname前缀，但这样做会违背不使用匈牙利表示法的目的。
反对匈牙利语的争论：
当在字段和变量的命名中使用匈牙利表示法时，会违反此规则。在C ++代码中使用匈牙利表示法已经很普遍，但C＃的趋势是为变量使用更长，更具描述性的名称，这些名称不是基于变量的类型，而是描述变量的用途。 / p>
计数器：
我提到的前缀不是基于变量的类型，前缀确实指定了变量的用途。
反对匈牙利语的争论：
现代代码编辑器（如Visual Studio）可以轻松识别变量或字段的类型信息，通常是将鼠标光标悬停在变量名称上。这减少了对匈牙利符号的需求。
计数器：
虽然这是真的，但除非发生错误，否则我自己几乎不会将鼠标悬停在变量名称上方。相反，使用匈牙利表示法，您可以立即看到您的变量在班级中的位置。
注：
Microsoft不推荐使用匈牙利表示法来表示文件名吗？我读到接口文件前缀为I是一种惯例，这是匈牙利表示法的一种形式。虽然这与我上面的问题没有直接关系，但它确实提出了有时建议使用匈牙利符号的观点。
答案 0 :(得分：10)
不，不要这样做。它使代码更难阅读。如果你用每个带有v_的动词和带有n_的每个名词写英文，这会使句子更难以阅读，同时添加大多数时候无用的信息。
如果你的课程设计得很好，责任和简短的方法很少，那么从名称和使用它的上下文中找出每个变量意味着什么并不困难。当它不明显且您需要知道时，很容易发现：您可以将鼠标悬停在变量名称上，或按“转到定义”。
StyleCop有rule，当您使用匈牙利表示法时会发出警告。规则描述对该规则存在的原因有一点解释：
<强>原因
C＃中的字段或变量的名称使用匈牙利表示法。
规则说明
当在字段和变量的命名中使用匈牙利表示法时，会违反此规则。在C ++代码中使用匈牙利表示法已经很普遍，但C＃的趋势是为变量使用更长，更具描述性的名称，这些名称不是基于变量的类型，而是描述变量的用途。 / p>
此外，现代代码编辑器（如Visual Studio）可以轻松识别变量或字段的类型信息，通常是将鼠标光标悬停在变量名称上。这减少了对匈牙利符号的需求。
答案 1 :(得分：4)
不，请勿使用匈牙利表示法。首先，它是20世纪90年代。其次，您的同事可能会对您进行殴打......; - ）
您的机器人示例：
Class.Robot或Robot
this.robot
robot
不需要匈牙利人。
答案 2 :(得分：3)
答案是否定的，正如大家在这里写的一样。
首先：你实际上没有使用hungarian notation - 或者它的一个已知变体 - 正如你自己在问题中陈述的那样。
因此，让我们从使用您自己制作的命名约定并且未广泛使用的问题开始。一旦您将代码暴露给现实世界（例如您的新同事），这就会立即导致问题。你只是在发明这种前缀表示法的私有第三（第n？）变体，其中包括迫使其他人不常见的所有问题包括。
现在 - 这是一个更好的变化吗？你是对的吗，其他人应该适应从这些规则中获益吗？
这里的共识似乎是“不”，我在这方面非常激烈。忽略关于匈牙利符号的标准论点（我将它们视为“不完全相关”）：
不要重复使用名称来表示很多事情。似乎仍然常见的一个例外是让构造函数接受与字段同名的参数：
public Foo（string robot）{ this.robot =机器人; }
如果您无法管理代码中的大量名称，那么您可能在一个地方/范围内拥有太多名称。你试图解决一个代码味道（臭，根据迄今为止的共识）解决方法
重申一次：你来到一个不使用你的会议的团队（他们怎么可能 - 这似乎是你自己制作的......）所以你必须适应团队。你可以争论个人的可读性，并可以自由地要求你的同事重新考虑，但如果他们不同意这种风格：不要反对。如果你坚持做对，他们就是错的，你只会让自己痛苦不堪。不要让这会降低你的工作效率。
答案 3 :(得分：2)
但是我喜欢在脑子里设置一个好的规则，我可以申请 一贯
甚至比头脑中的规则集更好，是IDE / build系统中的规则集：所以你应该看看StyleCop
StyleCop可让您按照自己喜欢的方式配置编码指南，但默认情况下提供了您所描述的匈牙利应用符号的流行替代方案：
this.myField this.MyProperty this.MyMethod() MyClass.MyStaticMethod() 你会在stackoverflow和其他地方找到关于编码风格这方面的无休止的讨论，所以我希望这个问题将作为一个副本关闭....
答案 4 :(得分：1)
我自己有一些我遵循的惯例。确实，现代的IDE会带走很多像这样的东西，但我仍然觉得有点匈牙利人:)。我正在使用：
robot_ for attributes（ms建议使用this.robot但是这样我不能忘记这一点）
camelCase用于局部变量和私有/受保护/内部方法
用于公共属性或方法的PascalCase
就是这样:)。我觉得代码看起来非常奇怪，所有这些m_，a_，...东西我觉得很难阅读。将鼠标悬停在VS中的代码上可以确保提示，但我发现使用某种约定会带来一些额外的好处。
我的意思是即使ms使用某种匈牙利符号来修复所有异步函数和Async，或者使用I前缀所有接口