在Java变量和方法名称中使用下划线[关闭]

83

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

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

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

java naming-conventions

— 乔治
source

146

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

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

— 坦塔卢斯
source

3

我们确实使用编码约定而不使用下划线。无论如何，在查看框架和较旧的代码时，我经常看到下划线。一致性规则高于约定的问题显然是为了一致性而要回答的，而不是我在问这个问题时想到的重点。

— Georgi

1

继续使用“ _”字符将是一个不好的做法。这种工作方式会带来额外的维护成本，您必须将这些特殊的约定告知加入该团队的每个新开发人员。

— 哈里尔

1

这就像这样命名接口：ReadableInterface-绝对冗余。在现代IDE中，您无需指定变量的类型或其范围-着色和快速跳转可为您完成所有工作。因此，IMO在输入多余字符并强迫人们阅读/维护它时是一种不好的风格。

— kiedysktos

120

sunDoesNotRecommendUnderscores因为JavaVariableAndFunctionNamesTendToBeLongEnoughAsItIs（）;

as_others_have_said_consistency_is_the_important_thing_here_so_chose_whatever_you_think_is_more_read（）;

— 安德斯·桑德维格（Anders Sandvig）
source

一致性规则优于约定的问题显然是为了一致性而要回答的，而不是我在问这个问题时想到的要点。无论如何，有时候您应该留下旧的痕迹，是吗？

— Georgi

2

如果已经使用了“冲突的”命名约定，我认为这取决于我们在谈论多少代码。考虑到始终使用旧的约定，我不建议只重写数千行代码以从old_convention转换为newConvention。

— 安德斯·桑德维格08-09-29

大声笑！话虽这么说，当代码被粘贴到具有拼写检查功能的编辑器中时，“拼写错误”的单词就会加上下划线，从而使下划线变得模糊。这是不使用下划线的一个很好的理由。此外，骆驼的情况下更短。最后，与在上一行（即，破折号'-'）相比，在字母上更容易使用Shift键。

— Tihamer

@Tihamer其他人则认为该snake_case表格更易于阅读。尤其是简短的单词（1-2个字母），我肯定会说是这样。至于“难于输入”，用lotsOfMixedCaseWithinIt输入单词也不是很方便。我主张这是您习惯的问题。但是在Java中，我说的是JLS / etc建议的“使用通用格式”。在Ruby / Python / C中，使用蛇形大小写。依此类推...

— Per Lundberg

37

规则：

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

— davetron5000
source

31

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

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

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

— 贾里德·帕
source

1

这个问题主要是关于Java下划线的问题，而不是仅关于成员变量的问题（尽管这是问题的一个示例）。

— Georgi

10

因此，您因为评论问题的一部分而将我打分吗？似乎有点极端

— JaredPar

1

@JaredPar-您是唯一提供出色替代样式建议的人。+1。

— djangofan 2013年

编写this.foo（或C ++中的this-> foo）可能是区分本地变量和字段/成员变量的一种更清晰的方法。

— 凯文

7

“不良风格”是非常主观的。如果某些约定对您和您的团队有用，那么我认为那将是坏/好风格。

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

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

— 克里斯多夫·赫雷曼
source

就像您说的那样，风格非常主观。this如果我认为需要引起注意，我倾向于使用比较宽松的方式来表示成员变量。但是，我不是狂热者。

— 克里斯·库德莫

6

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

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

— 尼古拉斯·曼库索（Nicholas Mancuso）
source

5

如果您正在编程Java，则很可能您将拥有一个IDE，该IDE将以不同的颜色为成员变量着色。“ m_”简直令人讨厌。

— JeeBee

我更喜欢“它”，因为它读起来很好：if (itsEmail.equals(email))

— davetron5000

7

我喜欢这个。会员名称。绝对无误。

— S.Lott

5

我碰巧喜欢（私有）实例变量的下划线，看起来更容易阅读和区分。当然，这件事会让您遇到一些麻烦的情况（例如，公共实例变量（我不知道，不常见）），无论您用哪种方式命名他们可能违反了您的命名约定：
private int _my_int; public int myInt;? _my_int? )

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

-自动化的代码生成（例如eclipse的生成getter，setter方法）不太可能理解这一点，因此您必须手工或用eclipse对其进行修复以使其能够被识别。

最终，您将与（java）世界的其他偏好相抵触，并且可能对此感到有些烦恼。而且，正如先前的海报所提到的那样，代码库的一致性胜过上述所有问题。

— 史蒂夫·B。
source

3

设置Eclipse以了解您的前缀（或后缀）首选项非常简单。在“首选项”->“ Java”->“代码样式”中，有一个表，您可以在其中设置字段，静态字段，静态最终字段，参数和局部变量的变量名称约定。所有代码生成器似乎都遵守这些设置。

— metasim

5

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

— 弗拉基米尔·米勒
source

这就是为什么OCaml永远不会在旧计算机上运行的原因。

— David Tonhofer

4

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

— 炒
source

4

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

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

— 马特
source

3

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

setBar( int bar)
{
   _bar = bar;
}

代替

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

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

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

— 克里斯·库德莫
source

在您的情况下，我使用以下命令：setBar（int aBar）{bar = aBar; }可读的，没有这个。或_bar ...

— Georgi

这很公平，但是aBar出现在API的方法签名中，我认为它看起来很乱。

— 克里斯·库德莫

1

实际上，我遇到了一种情况，即自动生成的代码与语言关键字之一匹配，因此，避免这种情况的最佳方法是在开头加上_。

— Joe Plante

2

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

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

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

— 乔·拉特泽
source

我在编码时大都同意“做别人做”的哲学，但并不是绝对的。我认为有一个很强的论点，即给定合理的标识符长度，snake_cased_variables比CamelCasedVariables更容易阅读。我的辩解是，从视觉上减轻认知负担是一件小事，但仍然很有用。在阅读文档和听音乐时，人们喜欢代码中的空白。我认为骆驼案以“效率”的名义冒犯了空白。谁的效率？

— David J.

2

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

public class TestClass {
  int var1;

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

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

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

在这种情况下，我通常将参数重命名为“ aVar1”。与“ var1”相反。

— Lluis Martinez，2009年

1

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

至少，像Eclispe的IDE是不可知的，允许像变量前缀或后缀，各种风格的大括号布局和空间管理等方面制定规则，以你可以沿着用它来重新格式化代码的指导方针。

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

— 菲L
source

0

这只是您自己的样式，没有不好的样式代码，也没有什么好的样式代码，只是将我们的代码与其他代码区分开。