Tabs vs Spaces：如何在Google，Twitter，Mozilla和Pied Piper上编写Java

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

尽管上面有暗示性的形象，我们也不想发动任何不必要的圣战。当归结为编码样式时，大多数选择都是相当随意的，并取决于个人喜好。是的，即使在编辑器之间制表符宽度改变了，空格也趋于更精确。

doSomethingIf

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

在这篇文章中，我们将重点介绍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％之间。

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

tabsvsspaces-768x356
Java Tabs vs Spaces –分析流行的代码约定（来源： outsideris / popularconvention ）

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％使用换行符：

花括号-768x360
块语句样式–分析流行的代码约定（来源： outsideris / popularconvention ）

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;
}