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

Question

即使现在我也经常在 Java 变量和方法中看到下划线。 一个例子是成员变量（如“m_count”或“_count”）。 据我所知，在这些情况下使用下划线被 Sun 称为不良风格。

它们唯一应该使用的地方是在常量中（例如“public final static int IS_OKAY = 1;”），因为常量应该全部大写而不是 骆驼案例。 在这里，下划线应该使代码更具可读性。

您认为在 Java 中使用下划线是不好的风格吗？ 如果是这样（或不是），为什么？

Answer 1

人们这样做的原因（根据我的经验）是为了区分成员变量和函数参数。 在Java中，你可以有一个这样的类：

public class TestClass {
  int var1;

  public void func1(int var1) {
     System.out.println("Which one is it?: " + var1);
  }
}

如果你将成员变量设置为_var1或m_var1，那么函数中就不会有歧义。

所以这是一种一种风格，我不会说它不好。

Answer 2

就我个人而言，我认为语言不应该制定关于编码风格的规则。 这是一个偏好、用法、便利性和可读性概念的问题。
现在，项目必须设置编码规则，以确保列表之间的一致性。 您可能不同意这些规则，但如果您想做出贡献（或在团队中工作），则应该遵守它们。

至少，像 Eclipse 这样的 IDE 是不可知的，允许设置变量前缀等规则或后缀、各种风格的大括号放置和空间管理等。因此您可以使用它按照您的指南重新格式化代码。

注意：我是那些保留 C/C++ 旧习惯的人之一，在 Java 中为成员变量添加 m_ 前缀（为静态变量添加 s_），在布尔值前添加首字母缩写前缀b，使用首字母大写字母作为函数名称并对齐大括号...Java 原教旨主义者的恐怖！ ;-)

有趣的是，这是我工作的地方使用的约定...可能是因为主要的初始开发人员来自 MFC世界！ :-D

Answer 3

这只是你自己的风格，不是坏风格代码，也不是好风格代码。 它只是将我们的代码与其他代码区分开来。

Answer 4

如果您现在没有代码使用它，我建议继续这样做。 如果您的代码库使用它，请继续。

编码风格最重要的是一致性。 如果您没有什么需要保持一致，那么语言供应商的建议可能是一个不错的起点。

Answer 5

sunDoesNotRecommendUnderscoresBecauseJavaVariableAndFunctionNamesTendToBeLongEnoughAsItIs();

as_others_have_said_consistency_is_the_important_thing_here_so_chose_whatever_you_think_is_more_readable();

Answer 6

规则：

1. 按照您正在编辑的代码执行操作
2. 如果 #1 不适用，请使用驼峰式命名法，无下划线

Answer 7

我不认为在 Java 或任何其他语言中使用 _ 或 m_ 来指示成员变量是不好的。 在我看来，它提高了代码的可读性，因为它允许您查看代码片段并快速识别出局部变量中的所有成员变量。

您还可以通过强制用户在实例变量前添加“this”来实现此目的，但我发现这有点严厉。 在很多方面，它违反了 DRY 因为它是一个实例变量。 为什么要两次合格呢？

我个人的风格是使用 m_ 而不是 _。 原因是还有全局变量和静态变量。 m_/_ 的优点是它区分变量的范围。 因此，您不能将 _ 重用于全局或静态，而是我分别选择 g_ 和 s_。

Answer 8

“糟糕的风格”是非常主观的。 如果某些惯例适合您和您的团队，我认为这将限定一种坏/好的风格。

回答你的问题：我使用前导下划线来标​​记私有变量。 我发现它很清晰，我可以快速浏览代码并找出发生了什么。

（不过，我几乎从不使用“this”，除非是为了防止名称冲突。）

Answer 9

在过去，使用下划线被认为是不好的风格是有原因的。 当运行时编译器价格昂贵且显示器具有惊人的 320x240 像素分辨率时，区分 _name 和 __name 通常并不容易。

Answer 10

以下是 Sun 针对 Java 的建议的链接。 并不是说您必须使用这些，甚至它们的库代码遵循所有这些，但如果您从头开始，这是一个好的开始。 像 Eclipse 这样的工具内置了格式化程序和清理工具，可以帮助您遵守这些约定（或您定义的其他约定）。

对我来说，“_”太难输入了:)

Answer 11

在变量前面使用“m_”或“_”可以更轻松地在整个对象的方法中发现成员变量。

作为一个附带好处，输入“m_”或“_”将使 intellsense 首先弹出它们；）

Answer 12

• 我碰巧喜欢（私有）实例变量的前导下划线。 看起来更容易阅读和区分。 当然，这可能会让你陷入边缘情况的麻烦（例如，公共实例变量（我知道，这并不常见）——无论你以哪种方式命名它们，你都可以说打破了你的命名约定：

  私有 int _my_int; 
    公共 int myInt;？   _我的_int？   ） 
    

• 正如我所喜欢的那样的 _style 并认为它是可读的，我发现它可能比它的价值更麻烦，因为它不常见，而且它可能与您正在使用的代码库中的其他任何内容都不匹配。

  自动代码生成（例如，Eclipse 的生成 getter 和 setter）不太可能理解这一点，因此您必须手动修复它或使用 Eclipse 进行足够的修改才能让它识别它。

最终，您将违背（Java）世界其他人的偏好，并且可能会因此而感到一些烦恼。 正如之前的发帖者所提到的，代码库的一致性胜过上述所有问题。

Answer 13

很高兴有一些东西来区分私有变量和公共变量，但我不喜欢一般编码中的“_”。 如果我可以在新代码中提供帮助，我就会避免使用它们。

Answer 14

它是编码风格的混合。 一种思想流派是在私有成员前面添加下划线以区分它们。

setBar( int bar)
{
   _bar = bar;
}

而不是

setBar( int bar)
{
   this.bar = bar;
}

Others 将使用下划线来指示临时局部变量，该变量将在方法调用结束时超出范围。 （我发现这毫无用处 - 一个好的方法不应该那么长，而且声明就在那里！所以我知道它超出了范围。）上帝禁止来自这所学校的程序员和来自会员数据学校的程序员合作！ 那将是地狱。

有时，生成的代码会在变量前面加上 _ 或 __。 这个想法是没有人会这样做，所以它是安全的。

Answer 15

我认为任何违反语言自身风格准则的风格（没有正当理由）都是丑陋的，因此是“糟糕的”。

毫无疑问，您所看到的代码是由曾经使用下划线可以接受的语言的人编写的。

有些人就是无法适应新的编码风格......