是否有任何广泛使用的现代 Java 编码约定？ [关闭]答案

【问题标题】：Are there any widespread, modern Java coding conventions? [closed]是否有任何广泛使用的现代 Java 编码约定？ [关闭]
【发布时间】：2009-09-01 23:50:18
【问题描述】：

Sun 的“Code Conventions for the Java Programming Language”最后一次更新是在 1999 年 4 月。十年后，语言和一般使用模式发生了很大变化。是否有更新的、被广泛采用的标准？

大多数指南都省略了指定文件编码和行尾。 Sun 建议混合制表符和空格。 Eclipse IDE 默认为 Eclipse 的标准，即仅选项卡。 Maven style guide 仅是空格。许多样式指南，例如JBoss，都遵循Sun 的指南，但更喜欢K&R 大括号而不是OTBS。每个 Apache 项目都有自己的风格指南，每个项目之间略有不同。

【问题讨论】：

我喜欢 Joel 对编码约定以及它们的意义的看法，但它们往往最终成为宗教，而对原因没有任何批判性思考：joelonsoftware.com/articles/Wrong.html
制表符：如果您使用任何胜任的编辑器，它可以并且将轻松地将制表符转换为您想要的任何令人赏心悦目的#空格。要微调代码的对齐方式，请使用空格。

标签： java tabs coding-style

【解决方案1】：

四个空格 - 这是上帝使用的。

【讨论】：

这是 Sun 使用的（至少对于 JDK）。
很有趣，我也是用的 ;)。说真的，尽管不必担心文件编码和行尾——我从未听说过在关于编码标准的讨论中出现这种情况。
这两个空格太多了。
@Tom H：Sun 可能指定他们使用 4 个空格，但如果你查看源代码，很明显他们将 8 个字符的制表符与空格混合在一起；无论是那个还是大多数核心库开发人员都不知道什么是好的缩进。
@Tom H：Sun 使用旧的默认 Emacs 格式，使用四个字符缩进，但使用制表符来实现每八个字符块的缩进，并用四个空格弥补差异。这可以追溯到一个使用超过 8 个字节的 1 个字节进行两级缩进（每行）开始增加实际存储空间和金钱的时代。

【解决方案2】：

您真正需要遵循的唯一编码标准是您的项目团队所接受的。您可能不同意制表符而不是空格，但如果这是您团队的编码约定，您最好遵守它。

【讨论】：

在试图让团队达成共识时，列出通用标准通常非常有用，因此您可以说：“我认为我们应该采用标准 X”或“标准 Y 被许多其他项目”。因此问题。
我同意。在尝试组建团队或建立共识时，您是绝对正确的。不幸的是，正如您所指出的，您的“通用标准列表”通常包含冲突！

【解决方案3】：

虽然它可能看起来过时了，但核心语言本身并没有添加太多内容（尽管库已经添加了很多很多内容）

我现在能记住的是enum 和泛型，其余的在第一次编写文档时已经存在。

始终使用 4 个空格。
不要使用 K&R 或 Allman：虽然它对于 C、C++ 和 C# 完全可以接受，但对于 Java 并非总是如此（除非项目明确决定使用它）。在 Java 中使用 K&R 或 Allman 在视觉上令人不快，因为它不会在 C 中使用。
始终使用大括号，包括单行语句。

一般来说，尽量不要在编程语言之间混合样式。就像自然语言中的口音发音，你可能听得懂，能读能写，语言有可操作的水平，但发音有缺陷只会惹恼母语者。

【讨论】：

我感觉发生了很多变化。无论是在功能方面，还是在人们如何使用语言方面。进化是为什么我们有 HashMap 而不是 Hashmap。该语言现在具有注释、静态导入、自动装箱、foreach 等。我什至发现很难阅读 Java 1.0-1.2 代码。 Unicode 很常见，以至于您现在可以在 cmets 和字符串中找到带有 Unicode 字符的程序。像“GNUmakefile - makefiles 的首选名称。”这样的项目可能会从 Sun 编码标准中删除。
什么？官方 C# 约定说不要使用 K&R。相比之下，官方的 Java 约定允许这样做。
@brianegge 你说得对，是奥尔曼风格没有 K&R
如果您建议不在 Java 中使用 K&R 或 Allman，您建议我们使用什么？我只见过在 Java 中使用这两个。
@BlueRaja-DannyPflughoeft 在 K&R 中，您可以将类和方法的左大括号放在新行中。把它放在同一行。不知道有没有名字

【解决方案4】：

问题不是问你的编码风格是什么，而是针对现有的编码标准。

我发现 European Space Agency Java Coding Standards (pdf) (alt link) 似乎是最新且全面的，但我不确定采用的范围有多广。

【讨论】：

“规则 1：使用 Apache Ant 工具自动构建您的项目。”我想这意味着现在有很多损坏的开源项目。 ;-)
是的，但这比 Sun 推荐的“GNUmakefile - makefile 的首选名称”要好。就标准而言，选择最后一个开发人员使用 Groovy/Ruby/Maven 等构建项目的项目是一件痛苦的事。只要您还提供或导出 ant 文件，您就可以使用 awk 编译您的项目。

【解决方案5】：

Ray Ontko 有一个Bibliography of Java Coding Standards。但很难将任何单一标准确定为“被广泛采用”。

【讨论】：

【解决方案6】：

考虑使用 IDE 的重新格式化机制默认使用的那个。从长远来看，将为您节省大量时间。

我们在 Eclipse 中启用保存操作并勾选 Format Source，以便始终重新格式化源。这意味着重新格式化只会更改自上次保存文件以来发生的事情。在源代码管理历史中很好。

您自然可以花时间定义自己的格式，但使用 Eclipse 标准往往会更容易——这对我们来说没问题。

【讨论】：

【解决方案7】：

查看Elements of Java Style

【讨论】：

这本书几乎和 Sun 的指南一样古老。
+1 这是一本出色的书，尽管年代久远，仍然适用。

【解决方案8】：

官方编码约定见此网址：http://www.oracle.com/technetwork/java/javase/documentation/codeconvtoc-136057.html

【讨论】：

【解决方案9】：

BSD/Allman 是唯一不错的缩进样式。它符合大括号的基本规则——如果它们位于不同的行上，它们应该位于同一列。与 K&R 相比，即使是 Horstmann 也是可以忍受的。

如果您在记事本中编码，请务必使用大括号。否则，由于 IDE 的自动缩进功能，它既无用又烦人。

【讨论】：