Answers:
当多个开发人员使用版本控制系统处理同一代码时，严格的代码格式设置规则将非常有用。如果不同的开发人员具有不同的格式规则，则合并可能会很痛苦，因为对于合并工具而言，相同的代码看起来会有所不同。
Eclipse（或与此相关的任何出色的IDE）具有可以在首选项部分（Java>代码样式>格式化程序）中自定义的代码格式化规则。选择您最喜欢的东西，但同时也要看一下Java标准代码约定。许多开源项目也都有自己的代码约定，可以使用Eclipse格式化程序强制实施。
此外，还有诸如CodeStyle，PMD和Findbugs之类的标准工具可以强制执行其他规则，并有助于避免常见的（低级）反模式和错误。
我发现自动格式化程序非常有用。您可以设置格式设置规则并让Eclipse为您设置代码格式（理想情况下自动使用“保存操作”自动设置格式），而不必一如既往地对应该如何格式化代码做出微妙的决定-容易出错并且会引起“认知冲突”- ）。当然，这需要您具有一致格式的代码库，或者具有根据您设置的规则重新格式化代码的权限。
启用“保存时自动格式化”有点像进行增量编译，它使您的大脑专注于代码本身，而不用担心诸如代码格式或语法之类的琐碎问题。
但是，是的，有时自动格式化程序会弄乱您拥有的一些格式良好的表。在这种情况下，我使用“开/关标签”。这些是在代码格式配置文件的“打开/关闭标签”选项卡下配置的。使用它们，您可以从自动格式化中排除代码中的区域：
// @formatter:off
... my nicely formatted table here ...
// @formatter:on
是否推荐它取决于您问的人。
我可以想象您会更喜欢自己格式化代码，毕竟，您知道自己最好的和最容易阅读的东西。从好的方面来说，如果您是一个体贴的人，也可以使其对其他人更易读。
机器没有这种预见性，并且可以（就像您说的那样）使您的代码看起来有些混乱，即使它们按照严格的规则对其进行了格式化。
一个好的IDE或工具通常可以为您格式化代码，做得很体面，但并不能总是使其尽可能地可读。
因此，我的建议是：除非您从别人那里收到代码，否则不要使用它，而且情况如此混乱，以至于您无法阅读它。
您应该一直使用它，以确保在所有源文件中使用一致的样式。这也将为您节省很多时间，您通常会花费这些时间来尝试手动调整格式。
Eclipse中的Java格式化程序做得很好，并且可以完全自定义。如果您不同意默认设置（我完全可以理解），则应将格式设置调整为自己的个人风格偏好或所使用的标准。您可以在Java /代码样式/格式器下的首选项中执行此操作。
当您不单独工作时，格式化程序会更加有用。您和您的团队成员很可能会在您认为完美的代码样式™上存在分歧。在这种情况下，您应该同意一个共同的基础，并为此一劳永逸地定义格式化程序规则。然后，每个人都可以点击格式快捷键，一切都符合商定的样式。这样一来，您的个人偏好（写作时）就不会受到影响。请注意，格式化程序样式可以存储在Eclipse的项目文件中，因此每个项目也可以使用不同的格式化程序。
尽管我喜欢在保存时自动格式化代码（实际上，我在个人项目中启用了它）。我发现我无法在使用基于Eclipse的产品的项目团队中完全推荐这种做法，因为Eclipse格式化程序存在一些严重的错误，使我无法推荐它。
具体来说，如果您启用了“代码清除” +“格式化程序”，则每次保存时缩进都会固定/不固定。
Eclipse的每个新版本都可能会更改格式器（更好），但是会进行重大更改，例如JavaDocs最终会在删除之后的多余空间，*但是在Helios和许多企业使用较早的Rational Software版本的eclipse之后才引入了以Helios为基础。
Eclipse提供的代码格式化程序无法按照其API进行扩展，实际上它明确声明了CodeFormatter javadoc
此类不打算由客户端子类化。
当然，到目前为止，我还没有找到任何可行的非商业替代方案。Jalopy多年没有更新，并且github中的fork尚未组织好，所以我不推荐它们。它也没有用于Eclipse集成的任何更新站点。我实际上计划将代码格式化作为构建的一部分，就像我使用Jalopy进行cleanpom-maven-plugin一样，但是由于缺少Jalopy的更新，所以这个想法被搁置了。