“代码格式化”提交到svn

Question

这个问题来自先前对svn的经验。

我们遇到的问题是我们的代码格式错误，主要是因为当时开发人员由于各种原因而不遵守格式指南而增加。因此代码格式存在差异很长一段时间。此外，代码库也很老了，所以它可能会持续多年。

无论如何，有人建议将新功能中所有触及的类格式化为我们商定的标准代码格式样式。其他开发人员反对这个主要是因为：

• 您不能使用代码的注释样式视图，因此您无法看到特定代码行与哪些功能相关。

最后，我们最终拒绝了这个想法，只对新引入的类文件进行了格式化。对于现有类中的新代码，我们只确保编辑的行正确缩进。

我们主要是eclipse用户，但我认为这个功能也可以在其他ide中使用（只需在网上查看netbeans和intellij）。

对于额外的上下文，有问题的代码库相当成熟，支持工作和新功能工作之间存在公平的平衡。有时候新功能会分成几个阶段，所以这也是需要考虑的事情。

所以问题是：

• 这是正确的做法吗？拒绝“代码格式提交”以保留注释的代码视图是否合理？
• 有更好的方法吗？我的观点是，也许应该有一个自动格式化的提交钩子，不确定这样的东西是否存在或者甚至是有效的？

Answer 1

你不想在钩子里这样做。不仅是一个非常糟糕的计划让钩子在传输过程中以任何方式编辑源，但是用户将得到的错误会很糟糕（不可能告诉用户所有错误都是有意义的在错误消息上的方式）。我不是一般的执行风格的粉丝..但如果你必须，我推荐一个三部分计划

1. 定义并记录您的编码风格。你提出的并不像讨论那么重要。
2. 为编辑导出配置并与团队共享。这将取决于编辑器。你想让它变得愚蠢，以便自动处理缩进和其他语法事务的苦差事。
3. 让您的CI强制执行该样式。如果你真的想强制执行它，你可以在这里做。可能与checkstyle类似。这将生成一个花哨的报告，显示并显示所有错误。

我参与了那些做得非常好的团队......标准非常灵活，每个人都觉得他们有输入，所以当构建失败时，没有抱怨。我们修理了它并继续前进。

我在一个团队中工作，一个非理性的法西斯主义者认为风格比代码的完整性或正确性更重要。它很糟糕。

就我个人而言，我会在第二步停下来，看看它在哪里得到你，然后再进入第3步。

Answer 2

在Eclipse中，在Preferences > Save Actions下，可以启用Auto Formatter格式化文件保存的代码。您可以将一组格式规则和Export Preferences File配置为发送给您的开发人员（或让领先的开发人员执行此操作），以便他们Import Preferences File，因此代码会在开发时自动格式化。< / p>

标准化的自动格式化程序有助于消除代码样式中的相似性，从而导致SVN中的非代码库更改。

Answer 3

我认为为你的仓库中的旧类做一次性代码格式化提交是完全没问题的，它的定义要好得多，然后在各处都有格式错误的代码。

至于IDE的Intellij和Eclipse可以在保存时进行格式化，但是我反对在钩子中进行格式化，因为它不知道你在编写什么，并且不会相信脚本。但这也可以起作用，但需要确保您用于格式化的内容完全符合任务