logo标签列表

在Java变量和方法名中使用下划线

javanaming-conventions
91
即使现在，我经常在Java变量和方法中看到下划线。一个例子是成员变量（如“m_count”或“_count”）。据我记得，在这些情况下使用下划线被Sun称为不好的风格。
唯一应该使用它们的地方是在常量中（例如“public final static int IS_OKAY = 1;”），因为常量应该全部大写而不是驼峰命名法。在这里，下划线应该使代码更易读。
你认为在Java中使用下划线是不好的风格吗？如果是这样（或不是），为什么？
对于使用 Kotlin 的开发者，Kotlin 建议使用下划线（_）作为私有属性的前缀。"如果一个类有两个概念上相同但一个是公共 API 的一部分，另一个是实现细节的属性，请使用下划线作为私有属性名称的前缀。"来源：(https://kotlinlang.org/docs/coding-conventions.html#names-for-backing-properties) - A-run
15个回答
152
如果你现在没有使用它的代码，我建议继续这样做。如果你的代码库使用它，请继续使用。
编写风格最重要的是保持一致性。如果你没有什么可以保持一致性的东西，那么语言厂商的建议可能是一个不错的起点。
3
我们确实使用编码规范，但不使用下划线。然而，在查看框架和旧代码时，我经常看到下划线的使用。关于一致性规则与惯例的问题，答案显然是要遵循一致性，但这并不是我在问这个问题时所考虑的重点。 - Georgi
1
继续使用下划线'_'字符将是一个不好的实践。这种工作方式会引入额外的维护成本，您将不得不向每个加入团队的新开发人员介绍这些特殊约定。 - Halil
1
这就像用这种方式命名接口：ReadableInterface - 完全是多余的。在现代 IDE 中，您不需要指定变量的类型或其范围 - 着色和快速跳转为您完成所有工作。因此，在我看来，这是一种糟糕的风格，因为您会输入冗余字符并迫使人们阅读/维护它。 - kiedysktos
126
sun不建议使用下划线，因为Java变量和函数名通常已经足够长了。

正如其他人所说，一致性在这里很重要，所以选择你认为更易读的方式。
一致性规则胜过传统的问题显然是为了保持一致性而回答，但这并不是我在提问时考虑的重点。无论如何，有时候你应该留下旧的痕迹，对吧？ - Georgi
2
如果“冲突”的命名约定已经在使用中，我认为这取决于我们谈论的代码量。如果旧约定被一致地使用，我不建议重写数千行代码以从old_convention转换为newConvention。 - Anders Sandvig
话虽如此，当代码被粘贴到具有拼写检查的编辑器中时，“拼错”的单词会被下划线覆盖。这是不使用下划线的一个很好的理由。另外，驼峰式命名法更短。最后，对于字母而言，按Shift键比按上排键（即Shift破折号“-”）更容易。 - Tihamer
@Tihamer 其他人可能会认为 snake_case 形式更易于阅读。特别是对于短单词（1-2个字母），我肯定会这样认为。至于“难以输入”，键入一个具有许多混合大小写的单词也不是很方便。我主张这是一个习惯问题。在Java中，我建议使用JLS /等推荐的常见形式。在Ruby/Python/C中，使用蛇形命名法。等等... - Per Lundberg
37

规则：

  1. 按照你正在编辑的代码所做的行事
  2. 如果 #1 不适用，则使用驼峰命名法，不要使用下划线
33
我认为在Java或其他语言中使用_或m_表示成员变量并不是坏事。在我看来，这样做可以提高代码的可读性，因为它允许您查看片段并快速识别出所有成员变量而不是局部变量。
您也可以通过强制用户在实例变量前加上"this"来实现此目的，但我觉得这有点严格。在很多方面，它违反了DRY，因为它本身就是一个实例变量。为什么要重复限定它呢？
我个人的风格是使用m_而不是_。原因是还有全局和静态变量。 m_/_的优点是它区分了变量的作用域。所以您不能将_用于全局或静态变量，而我选择分别使用g_和s_。
1
这个问题是关于一般情况下Java下划线的使用，而不仅仅是在成员变量中使用（尽管这在问题中是一个例子）。 - Georgi
10
你因为我评论了问题的一个子集而给我打分？这似乎有些过分。 - JaredPar
1
@JaredPar - 你是唯一一个提供了好的替代样式建议的人。对此点赞。 - djangofan
1
在编写代码时，使用this.foo（或C++中的this->foo）可能是一种更清晰的区分局部变量和成员变量的方式。 - Kevin
7
“不好的风格”是非常主观的。如果某个惯例适用于您和您的团队，我认为那就可以称为好/坏的风格。
回答您的问题：我使用前导下划线来标记私有变量。我发现这很清晰，可以快速扫描代码并找出正在发生的事情。
（但我几乎从不使用“this”，除非为了防止名称冲突。）
就像你所说的，风格是非常主观的。如果我认为需要引起注意，我倾向于自由地使用 this 来表示成员变量。然而，我并不是一个狂热者。 - Chris Cudmore
6

在变量前使用'm_'或'_'，可以更容易地在对象的方法中找到成员变量。

另外一个好处是，键入'm_'或'_'会使智能感知首先弹出它们 ;)

7
如果你在编写Java程序，很可能会使用一个集成开发环境(IDE)，该IDE会使用不同的颜色来显示你的成员变量。"m_"只是难看的。 - JeeBee
我更喜欢使用“its”，因为它读起来更顺畅：if (itsEmail.equals(email))。 - davetron5000
8
我更喜欢这个选项，用于成员名称。绝对不会出错。 - S.Lott
关于“在一个对象中”: 你是指“在一个类中”吗？ - Peter Mortensen
5
这里有一个指向Sun关于Java建议的链接。虽然你不必使用这些规范，甚至他们的库代码也未必都遵循这些规范，但如果你从头开始编写的话，这是一个不错的起点。像Eclipse这样的工具具备内置格式化和清理工具，能帮助你遵循这些规范（或自定义其他规范）。
对我来说，下划线太难打了 :)
5

  • I happen to like leading underscores for (private) instance variables. It seems easier to read and distinguish. Of course, this thing can get you into trouble with edge cases (e.g., public instance variables (not common, I know) - either way you name them, you're arguably breaking your naming convention:

    private int _my_int;
public int myInt;? _my_int? )

  • As much as I like the _style of this and think it's readable, I find it's arguably more trouble than it's worth, as it's uncommon and it's likely not to match anything else in the codebase you're using.

    Automated code generation (e.g., Eclipse's generate getters and setters) aren't likely to understand this, so you'll have to fix it by hand or muck with Eclipse enough to get it to recognize it.

最终，你将与（Java）世界的其他人偏见相违背，并可能遇到一些烦恼。正如之前的帖子所提到的，代码库中的一致性胜过以上所有问题。

3
将 Eclipse 配置为理解您的前缀（或后缀）偏好相当简单。在“首选项-> Java-> 代码风格”中有一个表格，您可以在其中设置字段、静态字段、静态常量字段、参数和局部变量的变量名称约定。所有代码生成器似乎都尊重这些设置。 - metasim
5

为什么在早期使用下划线会被认为是不良风格，这是有原因的。在运行时编译器还是无法承受的东西，显示器只有惊人的320x240像素分辨率的时代中，_name和__name之间往往很难区分。

这就是为什么OCaml永远不会在旧机器上运行的原因。 - David Tonhofer
4

区分私有变量和公共变量很好，但是我不太喜欢在编程中使用下划线。如果可以的话，我会避免在新代码中使用它们。

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接