Question

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

他们应该使用的唯一地方是常量（比如“public final static int IS_OKAY = 1;”），因为常量应该都是大写而不是驼峰。这里，下划线应该使代码更具可读性。

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

Answer 1

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

编码风格最重要的是一致性。如果您没有任何要求，那么语言供应商的建议可能是一个很好的起点。

Answer 2

sunDoesNotRecommendUnderscoresBecauseJavaVariableAndFunctionNamesTendToBeLongEnoughAsItIs();

as_others_have_said_consistency_is_the_important_thing_here_so_chose_whatever_you_think_is_more_readable();

Answer 3

规则：

执行您正在编辑的代码
如果＃1不适用，请使用camelCase，不要使用下划线

Answer 4

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

您也可以通过强制用户使用“this”预先添加实例变量来实现这一点，但我觉得这很苛刻。在许多方面，它违反了DRY，因为它是一个实例变量，为什么要对它进行两次限定。

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

Answer 5

“糟糕的风格”是非常主观的。如果某些约定适用于您和您的团队，我认为这将符合一个糟糕/好的风格。

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

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

Answer 6

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

输入'm_'或'_'作为附带好处会使intellsense首先弹出它们;）

Answer 7

我碰巧喜欢（私有）实例变量的前导下划线，它似乎更容易阅读和区分。当然这件事可以让你遇到边缘情况的麻烦（例如公共实例变量（不常见，我知道） - 要么你给它们命名的方式你可能会违反你的命名惯例：
private int _my_int; public int myInt;? _my_int? )

- 尽管我喜欢这种风格，并认为它的可读性让我发现它可能比它的价值更麻烦，因为它并不常见，并且很可能与您使用的代码库中的任何其他内容不匹配。

- 自动代码生成（例如eclipse的生成getter，setter）不太可能理解这一点，所以你必须手动修复它或者使用eclipse进行修复以使其识别。

最终，你要反对其余的（java）世界的prefs，并且可能会有一些烦恼。正如之前的海报所提到的，代码库的一致性胜过上述所有问题。

Answer 8

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

Answer 9

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

对我来说，'_'太难打字了：）

Answer 10

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

Answer 11

它是编码风格的混合体。一种思想流派是用私人成员作为下划线来区分它们。

setBar( int bar)
{
   _bar = bar;
}

而不是

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

其他人将使用下划线表示在方法调用结束时超出范围的临时局部变量。（我发现这很无用 - 一个好的方法不应该那么久，声明就在那里！所以我知道它超出了范围）编辑：上帝禁止来自这所学校的程序员和来自memberData学校的程序员合作！这将是地狱。

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

Answer 12

我认为任何破坏语言风格指导方针的风格（没有正当理由）都是丑陋的，因此“糟糕”。

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

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

Answer 13

人们这样做的原因（根据我的经验）是区分成员变量和功能参数。在Java中，您可以拥有这样的类：

public class TestClass {
  int var1;

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

如果你创建了成员变量_var1或m_var1，那么你就不会在函数中出现歧义。

所以它是一种风格，我不会称之为坏。

Answer 14

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

至少，像Eclispe这样的IDE是不可知的，允许设置变量前缀或后缀，各种样式的大括号放置和空间管理等规则。所以你可以用它来重新格式化代码你的准则。

注意：我是那些从C / C ++中保留旧习惯的人，用成员变量的m_前缀编写Java（和静态的m_编码），在布尔值前加上一个初始b，使用函数名的初始大写字母和对齐括号...... Java原教旨主义者的恐怖！ ;-)
有趣的是，这是我工作的惯例...可能是因为主要的初始开发者来自MFC世界！ :-D

Answer 15

这只是你自己的风格，没有什么不好的风格代码，也没有什么好的风格代码，只是将我们的代码与其他代码区别开来。

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

15 个答案: