89

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

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

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

4

15 回答 15

149

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

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

于 2008-09-29T19:17:43.573 回答
125 
sunDoesNotRecommendUnunderscoresBecauseJavaVariableAndFunctionNamesTendToBeLongEnoughAsItIs();

as_others_have_said_consistency_is_the_important_thing_here_so_chose_whatever_you_think_is_more_readable();
于 2008-09-29T19:41:39.693 回答
37

规则：

  1. 做你正在编辑的代码所做的事情
  2. 如果 #1 不适用，请使用驼峰式，不要使用下划线
于 2008-09-29T19:19:46.547 回答
33

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

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

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

于 2008-09-29T23:05:35.913 回答
7

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

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

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

于 2008-09-29T19:21:25.997 回答
6

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

作为附带好处，键入“m_”或“_”将使智能感知首先弹出它们；）

于 2008-09-29T19:18:35.350 回答
5

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

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

于 2008-09-29T19:55:07.040 回答
5
  • 我碰巧喜欢（私有）实例变量的前导下划线，它似乎更容易阅读和区分。当然这件事会让你在边缘情况下遇到麻烦（例如公共实例变量（不常见，我知道） - 无论你用哪种方式命名他们可以说是在打破你的命名约定：
  • private int _my_int; public int myInt;? _my_int? )

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

- 自动代码生成（例如 eclipse 的生成 getter、setter）不太可能理解这一点，因此您必须手动修复它或用 eclipse 弄脏它以使其识别。

最终，您将与（java）世界的其他首选项对抗，并且可能会因此而烦恼。正如之前的海报所提到的，代码库的一致性胜过上述所有问题。

于 2008-09-29T20:25:41.240 回答
5

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

于 2012-07-09T13:35:42.037 回答
4

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

于 2008-09-29T20:06:32.317 回答
3

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

setBar( int bar)
{
   _bar = bar;
}

代替

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

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

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

于 2008-09-29T19:20:35.780 回答
2

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

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

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

于 2008-09-29T19:20:51.553 回答
2

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

public class TestClass {
  int var1;

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

如果您将成员变量设置为 _var1 或 m_var1，则函数中不会有歧义。

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

于 2008-09-29T19:34:11.380 回答
1

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

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

注意：我属于那些保持 C/C++ 的旧习惯的人之一，使用 m_ 为成员变量（静态变量为 s_）编写 Java 代码，为布尔值加上首字母 b，使用首字母大写字母作为函数名并对齐大括号。 .. Java 原教旨主义者的恐怖！;-)
有趣的是，这就是我工作时使用的约定...可能是因为主要的初始开发人员来自 MFC 世界！:-D

于 2008-09-29T19:54:12.347 回答
0

这只是你自己的风格，没有不好的风格代码，也没有好的风格代码，只是我们的代码与其他代码不同。

于 2008-11-17T03:21:47.777 回答