流行的Java代码样式中最有趣的亮点是什么？

如果有开发团队人类学之类的东西，风格指南可能是其中的主要部分。

在这篇文章中，我们将重点介绍Google，Twitter，Mozilla，Java标准以及我们自己在Takipi团队中的公司的格式设置准则和不同的Java编码样式。

为什么首先使用准则？

可读性是这里的主要考虑因素。 几乎可以肯定，您将不是唯一阅读所编写代码的人。 对于下一个阅读您的代码的人，您可以做的最好的事情就是遵守约定。

一致的写作风格不仅有助于创建美观的代码，而且使其更易于理解。 Twitter指南指定了一个例外，我们倾向于同意：“如果更具可读性的变种带有危险或陷阱，则可能会牺牲可读性”。

完整的样式指南可在此处获得：

    Google Java样式指南 （还有另一本针对Android的指南） Twitter风格指南 官方Java代码约定 （可在此处获得新的OpenJDK指南） Mozilla准则 我们在塔基皮的准则

让我们看看他们的库存。

1.缩进：制表符与空格

首先，我们需要先解决这个问题，然后再继续。 样式指南中的选项卡上显然有空格优先。 我们不会在这里讨论利弊，而只是分享发现：

Google： 2个空格（android是4个空格，换行是8个空格） Twitter： 2或4个空格（用于换行） Mozilla： 4个空格 Java： 4个空格，制表符必须设置为8个空格。 两者都是可以接受的。

也许使用制表符的开发人员不喜欢编写样式指南＆＃55357;＆＃56841;。

来自Github的数据表明，大约10-33％的Java存储库更喜欢使用制表符，并且大多数使用不同形式的空格，而不是2优先使用4个空格。实际上有一个相当不错的模块可以运行此分析（比较不同的语言）。 顺便说一句，窥视Scala和Clojure等其他JVM语言，我们看到几乎100％2的空间。

考虑到覆盖个人提交的更大数据集给我们带来了不同的结果（ Convention Analysis项目 ， Github数据挑战赛的获胜者之一 ），但是我们可以估计它大约在10％之间。

（以防您好奇，在塔基皮我们更喜欢制表符。我们不是野蛮人。 去理查德·亨德里克斯！ ）

2.线长，绕线和断点

有时，Java代码的行数往往会很长，并且样式指南在何时中断或换行时设置了约定。 一般约定最大长度约为80-100

Google： 100列 Twitter：倾向于100列 Mozilla：适当的判断 Java： 80列

当然，除了分号后的自然中断外，不仅在行过长时使用换行符，而且还用于逻辑分离。 一般约定是在逗号前，运算符前打断，并使用一些常识。

这是twitter风格指南中的一个示例，充分利用了这一概念：

// Bad.
//   - Line breaks are arbitrary.
//   - Scanning the code makes it difficult to piece the message together.
throw new IllegalStateException("Failed to process request" + request.getId()
    + " for user " + user.getId() + " query: '" + query.getText()
    + "'");

// Good.
//   - Each component of the message is separate and self-contained.
//   - Adding or removing a component of the message requires minimal reformatting.
throw new IllegalStateException("Failed to process"
    + " request " + request.getId()
    + " for user " + user.getId()
    + " query: '" + query.getText() + "'");

这有助于分离语句并创建逻辑，其中每一行代码代表一个包含的“原子”操作。 样式指南倾向于在这里达成共识。

空行在混合中也起着重要作用，分隔逻辑块。 Java标准样式指南还参考了双换行符，将接口和实现分开。

3.变量命名

所有样式指南均达成广泛共识。 FirstLetterUpperCase用于类名camelCase用于方法和变量名，所有小写程序包名称，以及ALL_CAPS用于最终静态常量。 记录器是一个常见的例外，我们通常将其定义为：

private static final Logger logger = LoggerFactory.getLogger(Class.class);

Twitter的指南添加了另一种有趣的样式，即在变量名称中包含单位：

// Bad.
//   - Field names give little insight into what fields are used for.
class User {
  private final int a;
  private final String m;

  ...
}

// Good.
class User {
  private final int ageInYears;
  private final String maidenName;

  ...
}

4.异常捕获条款

例外是一个棘手的问题。 最近，我们进行了一项研究， 研究了Github和Sourceforge上的600,000个项目，并发现了有关非标准使用例外的严峻事实。 Google和Twitter的样式指南引用了臭名昭著的空白catch块：

Google：没有空的捕获块 Twitter：换句话说，不要吞下异常 Mozilla：无参考 Java：无参考

此外，我们建议至少尝试保留的另一项准则是确保异常是可操作的 ，并避免控制流异常。 在生产环境中引起的所谓“正常”异常的噪声数量令人恐惧。

Takipi的主要动机是，异常和错误处理的当前状态（主要依靠日志文件来确定其在生产中的根本原因）。 如果您还没有，请检查一下！ 我们很想听听您的想法。

5.括号清楚，花括号

即使没有必要，括号也可以帮助提高可读性。 对于复合谓词，即使执行顺序很明显，也通常使用括号来保持清晰。 例如：

if (x == y && a > 10) // bad
if ((x == y) && (a > 10)) // good

那么样式指南对分组括号有何看法？

Google： “推荐” Twitter： “明确”（即使很明显） Java： “通常是个好主意” Mozilla：遵循Java标准

处理花括号时，所有样式指南都检查了在打开花括号后支撑是否断裂。 在Takipi，我们实际上做了相反的事情，但我们并不孤单，尽管大多数Java开发人员都使用“行内”花括号，但此处检查的代码提交中有37％使用换行符：

6.建设者内无脑

我们保留但没有在任何样式指南中找到的一个准则是，不要在构造函数中保留任何“大脑”（因此，它们对于僵尸是安全的，但显然不会因薄弱的笑话而被拒绝）。

如果我们需要创建一个对象并进行一些繁重的操作来构建它，则可以使用creator方法。 例如：

/// simple constructor
//
private final int x;
private final int y;
private final String z;

public MyClass(int x, int y, String z) {
    this.x = x;
    this.y = y;
    this.z = z;
}


// complex building
//
public static MyClass create(List<Stuff> list, Set<Stuff> set) {
    // int x = some brains...
    // int y = more brains...
    // other brains...
    // String z = more complex stuff here
    //
    return new MyClass(x, y, z);
}

private final int x;
private final int y;
private final String z;

private MyClass(int x, int y, String z) {
    this.x = x;
    this.y = y;
    this.z = z;
}

最后的想法

为了避免使本指南成为详尽无遗的清单，我们在本文中没有涉及更多样式指南，这些指南都可以在本文开头链接的原始文档中找到。 可读性是保持代码无错误的主要因素，并且…防止这些OCD感觉发麻是正确的。

您要遵循哪些独特的准则/怪癖？ 您的公司/团队是否使用自己的风格指南？ 请随时在下面的评论部分中分享这些内容！

翻译自: https://www.javacodegeeks.com/2016/07/tabs-vs-spaces-write-java-google-twitter-mozilla-pied-piper.html