Jdbi: 决定奥尔曼与 K&R 的支撑位置并保持一致

是的，行尾的大括号对我来说很好。 我们可能应该在发布之前对代码风格做一次，有很多some_variable和诸如此类的东西，它们非常不像 Java

一个约定是局部变量的蛇形情况:-)

这在 Java 中并不常见，但后来，我越来越喜欢它，并且仍然习惯性地这样做，直到我停下来！

呵呵。 我们在JDBI里一直做Ning风格，为什么现在变了？

类和方法是“allman”风格，控制语句是 K&R 风格，因为它们在各自的情况下都具有更好的可读性。 此外，它是

if (...) {
...
}
else {
...
}

并不是

if (...) {
...
} else {
...
}

因为前者允许您选择完整的 else 块而无需光标左右移动，而后者则不允许（你好，窥视卡在 vi :-) ）。

无论我们做什么，我觉得是时候让 checkstyle 插件在构建过程中开始验证格式了。

啊，当然，自行车棚问题吸引了最多的评论；）

我也不在乎，坚持现有的风格很好，但我同意我们应该以一种或另一种方式强制执行它。

我建议切换到 K&R 样式，它使用 checkstyle 强制执行相当简单，并且通常设置为大多数 Java IDE 的默认值。

我个人喜欢 Allman 支架样式的外观。

但是我认为我们应该切换到 K&R，因为它是绝大多数 Java 开发人员使用的。 Allman 括号只是为 PR 添加工作。 例如https://github.com/jdbi/jdbi/pull/474#discussion_r77747433

事实上，我不介意更进一步，只是采用Google 的 Java 风格指南：

• 它有据可查，几乎每条规则都提供了理由。
• 它由 checkstyle 支持。
• 有一个Maven 插件可以将现有代码格式化为该样式。
• Google 为Eclipse和IntelliJ维护代码格式定义

我通常对 Google 的风格指南没意见。 然而，有些事情令人惊讶（似乎他们喜欢 2 个空格缩进？4 似乎是 Java 的标准），我担心它对于我们关心的内容来说过于指定了。 我可以看到我们花了相当多的时间来处理 Checkstyle，并对肛门内部间距规则感到沮丧 😒

我认为 #474 在某些情况下显示了 Allman 风格非常冗长。 特别是那个公关让我很恼火。

我们是否有任何数据支持“像 K&R 这样的 Java 程序员”的断言？ 我发现了这个：http://sideeffect.kr/popularconvention/#java
这似乎表明 K&R 的受欢迎程度是 Allman 的两倍，而且 5% 的程序员简直是疯了；)

当我们尝试移植功能时，这也会导致从 master 合并到 jdbi3 的痛苦。
我想我倾向于“K&R 风格的大括号，强烈鼓励 Google Java 风格，但不是 100% 要求，只是让代码可读” - 我们可以启用我们认为比烦人更有用的任何检查器子集。

我也会记录在案，因为无论哪种方式都不太关心这个。 我喜欢可读的代码而不是关于样式规则的争论:)

我们现在把这个放在桌子上怎么样。 当我们准备好回到这一点时（在发布即将结束时），我会在切换到 Google 风格上做一个高峰，然后我们可以根据观察到的影响进行辩论。

我们在 Airlift 和 Presto 中使用了 Ning 风格（我猜那是@martint风格）的衍生物，并且与 Jdbi 现在使用的非常接近。 我们的 Checkstyle 规则已经足够好了，因为在代码审查中格式化 nits 相对较少。

在 Travis 中运行检查器意味着人们可以在审查之前看到它并修复它。 我认为，从心理上讲，当这是自动作为构建的一部分时，人们会更容易接受。 没有人争论样式规则，他们只是注意到构建失败并修复它。 强烈推荐，无论您选择什么风格。

IntelliJ： https :
检查样式： https :

查看了谷歌代码格式化程序和 checkstyle 中预设的谷歌代码样式 - 这可能比它的价值更麻烦。

@jdbi/contributors 如果团队的其他成员都同意，我很乐意关闭它。

所有自行车棚的颜色都很重要：P