3

我知道这个问题已经被问了一点，从表面上看，这个问题没有明确的是或否答案，但我仍然对某些事情感到有些困惑。

通常当我编程时，我会遵循一些关于前缀的规则：

  • m_ 在成员面前
  • p_ 在属性前面
  • s_ 在 static 前面
  • a_ 在参数前面
  • l_ 在局部变量前面

我现在得到了一份新工作，我注意到代码中没有使用前缀。我问为什么，他们回答说 IDE 完成了跟踪什么是成员变量和什么是局部变量的所有工作。现在我在想，可能是这样，但是使用前缀不是更容易吗？

我的意思是，如果我有一个成员、一个静态变量和一个名为“robot”的局部变量，那么在编写方法时引用它会不会很痛苦？这可能是一个不切实际的例子，但我喜欢在我的脑海里有一个很好的规则集，我可以始终如一地应用它，即使是在不切实际的情况下。

这个例子是否证明使用匈牙利符号是合理的？

我想我会制作一个优点/缺点列表并在我了解更多信息时对其进行编辑。

反对匈牙利语的论点：

Class.Robot或者Robot

this.robot

robot

不需要匈牙利语。

柜台：

仍然存在不一致之处，机器人可能以不同的方法表示不同的东西。为了保持一致，您应该在每个 Robot 变量之前添加 Class 或 this（或无）前缀。

最重要的是，假设您要访问静态变量 Strawberry，您怎么知道未定义名为 Strawberry 的成员变量？也许它是在另一个你看不到的文件中定义的，所以你可能会得到意想不到的结果。现在您可能会说这可以通过 IDE 看到，但我认为使用前缀更好，因为您可以看到您所引用的内容，而您可能会错过 IDE 告诉您的内容。当然，您也可以使用 this/Classname 前缀，但这违背了不使用匈牙利符号的目的。

反对匈牙利语的论点：

如果在字段和变量的命名中使用匈牙利符号，则会违反此规则。匈牙利符号的使用在 C++ 代码中变得普遍，但 C# 的趋势是为变量使用更长、更具描述性的名称，这些名称不是基于变量的类型，而是描述变量的用途。

柜台：

我提到的前缀不是基于变量的类型，前缀确实指定了变量的用途。

反对匈牙利语的论点：

现代代码编辑器（例如 Visual Studio）可以轻松识别变量或字段的类型信息，通常通过将鼠标光标悬停在变量名称上。这减少了对匈牙利符号的需求。

柜台：

虽然这是真的，但我自己几乎从不将鼠标悬停在变量名上方，除非发生错误。相反，使用匈牙利表示法，您可以立即看到变量在类中的位置。

评论：

Microsoft 不建议对文件名使用匈牙利符号吗？我读到用 I 前缀接口文件是一种约定，这是匈牙利符号的一种形式。虽然这与我上面的问题没有直接关系，但它确实提出了匈牙利符号有时被推荐的观点。

4

5 回答 5

10

不，不要这样做。它使代码更难阅读。如果你写英语时每个动词前面都带 v_，每个名词都带 n_，这会使句子更难阅读，同时添加大部分时间无用的信息。

如果你的类设计得很好，职责很少，方法也很短，那么从名称和使用它的上下文中弄清楚每个变量的含义应该不难。当它不明显并且您需要知道时，很容易找出：您可以将鼠标悬停在变量名称上，或按“转到定义”。

StyleCop 有一条规则，当您使用匈牙利符号时会发出警告。规则描述对为什么存在该规则有一点解释：

  • TypeName FieldNamesMustNotUseHungarianNotation
  • 检查 ID SA1305
  • 类别命名规则

原因

C# 中的字段或变量的名称使用匈牙利表示法。

规则说明

如果在字段和变量的命名中使用匈牙利符号，则会违反此规则。匈牙利符号的使用在 C++ 代码中变得普遍，但 C# 的趋势是为变量使用更长、更具描述性的名称，这些名称不是基于变量的类型，而是描述变量的用途。

此外，现代代码编辑器（例如 Visual Studio）可以轻松识别变量或字段的类型信息，通常是将鼠标光标悬停在变量名称上。这减少了对匈牙利符号的需求。

于 2011-11-30T23:36:24.457 回答
4

不，不要使用匈牙利符号。首先，现在是 1990 年代。其次，你可能会被你的同事殴打...... ;-)

您的机器人示例：

Class.Robot或者Robot

this.robot

robot

不需要匈牙利语。

于 2011-11-30T23:32:48.823 回答
3

答案是否定的，因为每个人都已经在这里写过。

首先：您实际上并没有使用匈牙利符号- 或它的已知变体 - 正如您自己在问题中所说的那样。

因此，让我们从您使用的命名约定开始，这种命名约定是您自己制定的，并未广泛使用。一旦您将代码暴露给现实世界（例如您的新同事），这就会立即导致问题。您只是在发明此前缀符号的私有第三个（第 n 个？）变体，其中包含将某些不常见的东西强加给其他人的所有问题。

现在 - 这是一个更好的变化吗？你是对的，其他人应该适应从这些规则中获益吗？

这里的共识似乎是“不”，我强烈支持这一点。忽略关于匈牙利符号的标准论点（我认为它们“不完全相关”）：

  • 不要重复使用名称来表示很多事情。一个似乎仍然很常见的例外是让构造函数采用与字段同名的参数：

    公共 Foo（字符串机器人）{ this.robot = 机器人；}

  • 如果您在管理代码中的大量名称时遇到问题，则很可能您在一个地方/范围内有太多名称。您正在尝试使用（根据目前的共识，臭味）解决方法来解决代码异味

  • 重申一次：你来到一个不使用你的惯例的人的团队（他们怎么可能 - 这似乎是你自己制造的......）所以你必须适应团队。你可以争论个人的可读性，也可以要求你的同事重新考虑，但如果他们不同意这种风格：不要反对。如果你坚持正确而他们是错误的，你只会让自己痛苦。不要让这消耗您的生产力。

于 2011-12-01T14:19:48.747 回答
2

但我喜欢在我的脑海里有一个很好的规则集，我可以始终如一地应用

比你头脑中的规则集更好的是，你的 IDE/构建系统中的规则集：，所以你应该看看StyleCop

StyleCop 将让您根据自己的喜好配置您的编码指南，但默认情况下，它会为您描述的应用程序匈牙利符号提供一种流行的替代方案：

  • 领域：this.myField
  • 特性：this.MyProperty
  • 方法：this.MyMethod()
  • 静力学：MyClass.MyStaticMethod()
  • 等等

你会在 stackoverflow 和其他地方找到关于编码风格这方面的无休止的讨论，所以我希望这个问题将作为重复关闭......

于 2011-11-30T23:42:28.893 回答
1

我自己有一些我遵循的约定。的确，现代 IDE 带走了很多这样的东西，但我仍然觉得有点匈牙利语:)。我在用着：

robot_ 用于属性（ms 建议使用 this.robot 但像这样我不能忘记 this）
camelCase 用于局部变量和私有/受保护/内部方法
PascalCase 用于公共属性或方法

就是这样:)。我认为所有这些 m_、a_、... 的代码看起来很奇怪，我觉得很难阅读。将鼠标悬停在 VS 中的代码上肯定会给你一些提示，但我看到使用某种约定有一些额外的好处。

我的意思是即使 ms 使用某种匈牙利符号来为所有异步函数添加 Async 后缀或在所有接口前添加 I

于 2011-11-30T23:40:46.103 回答