大型项目代码格式化的最佳实践[关闭]

Posted 2023-02-27

【中文标题】大型项目代码格式化的最佳实践[关闭]

【英文标题】：Best practices for code formatting on large projects [closed]

【发布时间】：2010-12-29 15:45:29

【问题描述】：

我维护了一个大型 Java EE/Maven/Hudson/Perforce 项目的构建，其中约有 20 名开发人员分布在世界各地。

代码格式化的就地解决方案是在开发人员运行构建时使用Jalopy 格式化代码库，从而确保在签入之前对任何未格式化的代码进行格式化。

这个解决方案的主要问题是，如果开发人员在签入之前没有运行完整的 Maven 构建（比如他们从 Eclipse 运行单元测试），他们的代码将不会被格式化。然后，下一个编辑文件的开发人员在运行格式化程序后，可能在代码的不相关部分有很多很多差异。

在大型项目中，哪种源格式设置策略最适合您？我考虑过的另一个选择是使用自动化流程在夜间格式化。

【参考方案1】：

Maven 构建应该只是使用 Checkstyle 之类的东西报告格式错误，而不是自动格式化代码。你的描述似乎就是这个意思。这样，错误就会在构建时报告给开发人员/Hudson，并且可以根据需要解决。

我还建议使用Sonar 之类的工具来记录格式错误随时间推移的历史记录（请参阅他们的时间机器功能）。

【参考方案2】：

为了使您的项目格式一致，您需要配置工具以自动执行此操作。我建议如下：

Eclipse 格式化程序

对于 Eclipse，在 Preferences (Java->Code Style->Formatter) 中有一个选项，您可以在其中配置您希望如何格式化项目。创建一个新的配置文件并将您的配置放在那里。

完成后，有一个导出功能（它隐藏得很好，点击编辑然后导出）。将配置传递给团队的其他成员，以便他们可以导入它。

Eclipse 保存操作

仍然配置格式化程序并不能保证开发人员在提交之前会格式化代码，因此您需要配置自动格式化。

再次转到首选项（Java->Editor->Save Actions）并选择格式化源代码。这样代码在保存文件时就被格式化了。

Eclipse Checkstyle 插件

一些开发人员可能会忘记正确执行这些步骤，因此您需要一种方法来找到它。

为 Eclipse 安装 Checkstyle 插件：

转到帮助->安装软件... 添加http://eclipse-cs.sf.net/update/ 安装最新的 checkstyle 插件

安装插件后，您可以为其创建配置。然后可以为团队的其他成员导出配置，或者更好地上传到服务器并远程引用配置。

拥有远程配置的好处是您还可以通过 maven-checkstyle-plugin 引用它，它可以通过在 CI 服务器上启动它来为您提供报告。

如果您想成为硬核，您可以将基本配置（由格式化程序自动完成的配置）设置为错误而不是警告，以便开发人员在 Eclipse 配置错误之前看到错误。

预配置的 Eclipse

如果您想更上一层楼，您可以创建一个预配置的 eclipse，然后将该版本分发给您的开发人员，这样他们就不需要做任何事情。

副作用奖励：您可以避免开发平台上的版本不一致。配置管理不仅涉及源代码，还涉及开发工具。让事情更加可预测。

【讨论】：

Eclipse 是一种重新格式化代码的糟糕方法。我们的经验是它不会始终如一地重新格式化每个文件，因此它会随着时间的推移在分支之间产生差异。 Jalopy、Jacobe、JIndent 或类似的东西更可取。

【参考方案3】：

处理此问题的一种方法是使用Jalopy 或JIndent 甚至Eclipse 内置代码格式化程序（您可以invoke from the command line）在预提交挂钩中格式化代码。 AFAIK，如果您不能强制人们在提交之前运行自动构建，这是确保版本化代码始终正确格式化的唯一方法。但我不知道 Perforce 是否支持预提交挂钩。

如果没有，另一种选择是在构建时使用Jalopy Maven Plugin 或Maven Checkstyle Plugin，并在规则被破坏时使构建失败（并让 CI 引擎报告它）。不过，外观方面的构建失败可能会很烦人。

因此，确实，每晚运行一个进程来格式化代码可能是一种替代方法。在这种情况下，Jalopy Maven Plugin 或其他提到的工具可能会对您有所帮助，这实际上取决于您是否要使用 Maven 来完成这项工作。

【参考方案4】：

如果您的所有（或大多数）开发人员都在使用 Eclipse，您可以根据团队的喜好导出格式化规则并保存操作，并让每个人都共享相同的偏好。

【讨论】：

我已经多次看到这个失败了。如果使用 Maven/Checkstyle/Hudson 将规则集成到自动构建过程中，我发现跟踪/执行规则会容易得多。

我并不是说这是你唯一要做的事情。你当然应该仍然使用 Checkstyle - 这只会在编写代码时更容易修复格式，而不是事后。

在这种情况下，我建议使用 Checkstyle Eclipse 插件并将其配置为使用与 Hudson 相同的规则。

【参考方案5】：

我见过的最佳解决方案是CXF 采用的方法，Connecting Maven, Eclipse, Checkstyle, and PMD 中有详细描述。

他们使用另一个回复中提到的 Eclipse-cs 插件 Dimitris 将 checkstyle 与 Eclipse 集成。这允许 Eclipse 在其代码违反任何代码格式规则时生成错误。他们还将 checkstyle 与Maven 集成在一起，因此如果他们的代码不符合 checkstyle 规则，验证步骤将失败。它们还在 Eclipse 中定义了一组冗余的自动格式化规则，这使得快速格式化将通过 checkstyle 标准的代码变得容易。

这意味着 Eclipse 需要进行大量配置。他们通过将一组 Maven 插件组合在一起来自动执行此步骤，这些插件将生成一个特定于 CXF 的工作区，其中包括必要的检查样式/自动格式化配置。

【参考方案6】：

你可以在 Perforce 中设置一个签入规则来格式化签入代码吗？我没有使用过 perforce，因此无法发表评论 - 但当我们在团队中讨论代码格式强制执行选项时，我们认为这是合适的。

【参考方案7】：

这可能没有多大帮助，但Go language source tree 会使用他们设置的命令行应用程序自动格式化您推入其中的内容。它是在 Mercurial 中完成的，而不是 Perforce。但是，也许你可以看到他们是如何做到的。详细信息必须在golang.org 中的某处。

【参考方案8】：

如果正确的格式化对你来说很重要，那么配置 Perforce 在签入时运行自己的格式化，并告诉它在源文件的格式化版本与提交的版本不同时拒绝提交。

就个人而言，我们只是使用 Eclipse Save Actions，并在保存时告诉它重新格式化。对我们来说已经足够了。