即使在今天，我也经常在Java变量和方法中看到下划线，例如成员变量(例如" m_count"或者" _count")。据我所记得，在这些情况下使用下划线被Sun称为"坏样式"。

应该使用它们的唯一位置是常量(例如" public final static int IS_OKAY = 1;"中的常量)，因为常量应该全部为大写而不是驼峰式。在这里，下划线应使代码更具可读性。

我们认为在Java中使用下划线是不好的风格吗？如果是(或者不是)，为什么？

解决方案

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

编码风格最大的优点就是一致性。如果没有什么不符合的地方，那么语言供应商的建议可能是一个不错的起点。

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

作为附带好处，键入'm_'或者'_'将使智能首先弹出它们；)

规则：

• 做我们正在编辑的代码
• 如果＃1不适用，请使用camelCase，不要使用下划线

它是编码风格的融合。一种思路是在私人成员的前面加上下划线以区别他们。

setBar( int bar)
{
   _bar = bar;
}

代替

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

其他人将使用下划线指示临时局部变量，该临时局部变量将在方法调用结束时超出范围。 (我发现这没什么用，一个好的方法应该用不了那么长的时间，并且声明是正确的！所以我知道它超出了范围)编辑：上帝禁止这个学校的程序员和memberData学校的程序员合作！真是地狱。

有时，生成的代码会将变量以_或者__开头。这个想法是没有人会这样做，所以很安全。

我认为任何违反语言自身风格准则(没有正当理由)的风格都是丑陋的，因此是"不好的"。

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

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

"不良风格"是非常主观的。如果某些约定对我们和团队有用，那么我认为这将是一种不好/好的风格。

回答问题：我使用前划线来标记私有变量。我发现它很清楚，我可以快速浏览代码并找出正在发生的事情。

(不过，除了防止名称冲突外，我几乎从不使用" this"。)

人们这样做的原因(以我的经验)是区分成员变量和函数参数。在Java中，我们可以拥有这样的类：

public class TestClass {
  int var1;

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

如果使成员变量_var1或者m_var1，则函数中将不会有歧义。

所以这是一种风格，我不会认为这很糟糕。

sunDoesNotRecommendUnderscoresBecauseJavaVariableAndFunctionNamesTendToBeLongEnoughAsItIs();

as_others_have_said_consistency_is_the_important_thing_here_so_chose_whatever_you_think_is_more_readable();

就个人而言，我认为一种语言不应制定有关编码风格的规则。这是喜好，用法，便利性和可读性的概念。
现在，一个项目必须设置编码规则，以确保清单之间的一致性。我们可能不同意这些规则，但是如果我们想做出贡献(或者在团队中工作)，则应该遵守这些规则。

至少，像Eclispe这样的IDE是不可知的，它允许设置诸如变量前缀或者后缀，各种样式的花括号放置和空间管理等规则，因此我们可以使用它按照准则重新格式化代码。

注意：我属于那些遵循C / C ++习惯的人，在Java中用成员变量的m_前缀编码(对于静态变量用s_前缀)编码，以布尔值开头的b前缀，使用大写字母开头的函数名称以及大括号对齐。 .. Java原教旨主义者的恐怖！ ;-)
有趣的是，这是我工作时所使用的约定……可能是因为主要的初始开发人员来自MFC世界！ :-D

这是Sun针对Java的建议的链接。并非必须使用这些代码，甚至不必遵循它们的库代码，但是如果我们是从头开始的话，这是一个很好的开始。 Eclipse之类的工具内置了格式化程序和清除工具，可以遵循这些约定(或者我们定义的其他约定)。

对我来说，'_'太难键入了：)

有一些东西可以区分私有变量和公共变量，这很好，但是我不喜欢通用编码中的" _"。如果可以在新代码中提供帮助，请避免使用它们。

• 我碰巧喜欢在(私有)实例变量前加下划线，这似乎更容易阅读和区分。当然，这件事会让我们遇到一些麻烦的情况(例如，公共实例变量(不常见，我知道))–我们可以用两种方式命名他们可能违反了命名约定：
• private int _my_int; public int myInt ;? _my_int？ )

-尽管我喜欢它的_style并认为它是可读的，但我发现它可能是麻烦的多于其价值，因为它不常见，而且很可能与我们使用的代码库中的任何其他内容都不匹配。

-自动代码生成(例如eclipse的generate getters，setters)不太可能理解这一点，因此我们必须手工或者用eclipse对其进行修复以使其能够被识别。

最终，我们将与(java)世界的其他偏好相抵触，并且可能对此感到有些烦恼。而且，正如先前的海报所提到的那样，代码库中的一致性比上述所有问题都重要。

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

我们也可以通过强制用户在实例变量之前加上" this"来实现此目的，但是我发现这有点过分苛刻。它在许多方面违反了DRY，因为它是一个实例变量，为什么要对它进行两次限定。

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

这只是我们自己的样式，没有不好的样式代码，也没有什么好的样式代码，只是我们的代码与其他代码有所不同。