6

我们的团队最近继承了非常混乱的代码。

因此，我的团队领导决定在保存文件之前强制执行代码自动格式化的策略。我们甚至在 Eclipse（我们选择的 IDE）中找到了一个选项，可以在每次保存操作之前自动格式化代码。

我个人反对它，因为我认为正确的编码可以防止混乱的代码（大多数时候），而自动格式化并不意味着正确的编码。

你有什么意见？

4

12 回答 12

16

恕我不能赞同。对我来说，格式化，即使只是“呈现”源代码的一种方式，也是一个重要的代码质量指标。

使用自动格式化有几个优点。它使团队所有开发人员的格式同质化。这将避免您在处理 SCM 时遇到一些麻烦：例如，合并两个几乎没有实际更改但格式差异很大的文件是一场噩梦！

它还可以向您显示一些错误。例如：

if (aCondition)
    foo();
    bar();

将被重新格式化：

if (condition)
    foo();
bar();

表明第二行不在if语句中。

最后但同样重要的是，格式良好的代码（不仅适用于 Java）更易于阅读！

于 2009-11-04T14:51:03.863 回答
8

只对继承的代码进行一次自动格式化，然后继续进行而不进行自动格式化。

于 2009-11-04T14:47:44.167 回答
5

在我看来，一致的代码格式提高了易读性。它显然不能替代好代码，但另一方面，最出色的结构草率也不能称为好代码。

对我来说，自动格式化的问题主要是它扰乱了版本控制系统。然而，一次格式的转换 - 无需任何其他更改 - 可能会很好地改善工作流程。

于 2009-11-04T14:52:39.990 回答
3

我和你的团队负责人在这个问题上，我有两个建议给你：

  1. 保存每个文件一次，其中唯一的更改是带有反映所有更改的提交消息的格式，然后返回并进行实际的代码更改。当您需要进行差异更改时，这将为您节省大量时间。格式修订版几乎每行代码都会更改，因此实际上不可能在同一修订版上找到真正的更改。

  2. 就编码标准达成一致并定制 Eclipse 的自动格式化工具以遵循该标准。

于 2009-11-04T15:19:38.227 回答
3

一致的代码格式确实有助于在提交代码时进行差异化等。

我已经将我的源代码控制脚本配置为在推送时自动格式化为“house style”，并在拉动时自动格式化为我喜欢的风格，所以每个人都很高兴。

我建议你考虑相同。

于 2009-11-04T14:54:56.867 回答
2

作为开发团队的负责人，我反对自动格式化。因为可读的代码很重要，所以负责任的开发人员可以在他们认为必要的时候格式化他们的代码是很重要的。自动格式化程序可能会破坏精心制作的评论，它们会删除为清晰而插入的额外空行等。

我们使用像 checkstyle 这样的插件，必须遵守标准规则集，签入的代码应该没有 checkstyle 警告。如果出现一些非结构化代码，eclipse 格式化程序可以进行第一次清理和检查样式，并且朋友们指出了需要解决的问题。

于 2009-11-04T17:14:04.463 回答
2

取决于你所说的“杂乱无章”是什么意思。我们是在谈论风格上的不一致，还是说班级结构是一个难以理解的大杂烩？如果您通过自动格式化程序解决它，我猜是前者。

“正确编码”并不一定意味着“在开发人员之间保持一致”。如果我将我的编辑器设置为四格硬制表符，而您将您的编辑器设置为三格软制表符，那么我们共同编写的代码将看起来很糟糕。（我们的项目经理可能应该让我们俩都头脑发热，让我们知道我们应该使用什么标准。）

自动格式化程序是一种蛮力解决方案，几乎可以保证偶尔会将一些不寻常但完全可读的东西变成一团糟。如果代码真的那么乱，那么这是一个明智的起点。但是，一旦您从预先存在的代码中自动格式化了 Suck 的大部分内容，您最好建立团队首选的样式约定并从那里着手。

于 2009-11-04T14:58:22.990 回答
2

我们实际上在 Eclipse 中使用了自动格式化，这通常会降低我的代码的可读性，例如通过插入许多换行符。当我们迁移到新的 eclipse 版本时，尽管我们使用了相同的设置，但格式并不相同。与版本控制系统相结合，这是一个巨大的缺点。我更喜欢 CheckStyle 插件来实现一致的代码风格。

但如前所述，我会在重构文件时使用一次自动格式化。

于 2009-11-04T14:54:01.733 回答
1

我认为您的代码格式很重要。给出的例子确实突出了像这样的愚蠢错误潜入的可能性，尽管我会用这个例子来争论总是使用大括号！

我发现在查看具有各种不同格式的源文件时，您必须更加努力地理解代码。常规代码模式更容易理解语义，因为语句都“在正确的位置”。

我不确定“正确编码”是什么意思，因为对于“正确”的构成似乎有点模棱两可。有些语言结构在正常情况下可能永远不应该使用，而软件工程反模式则应该避免。如果这些事情是正确编码的意思，那么确保这些事情很重要，但它们不会反映源文件文档的格式。

有一些工具可以通过违反格式化构建失败来强制在源文件中进行代码格式化。起初我对这样的工具持怀疑态度，因为它们看起来有点苛刻，但我发现让代码结构统一可以真正提高生产力。

PS 最后的声明完全是轶事，因为我没有指标来支持它。

于 2009-11-04T15:11:04.273 回答
0

格式化代码非常重要：

  • 通过保持代码正确缩进，用户可以更轻松地浏览中型或大型文件。
  • 通过在所有项目中保持一致的编码风格，当人们转移到其他项目时，他们会更加熟悉代码。当然，这也与编码指南、如何命名变量等有关，这些也应该在一个共同点上相对规范化。
  • 如果您花一些时间制定正确的代码格式规则，您还可以保证更多用户可以查看代码（不幸的是，我不得不在文本中手动编辑代码 [想想记事本或 emacs] 很多次，通过设置行长到 80 列左右，它可以提供帮助）
  • 最重要的是，通过保持格式一致，您可以更轻松地区分两个文件
于 2009-11-04T15:19:14.513 回答
0

在您的职业生涯中，您需要遵守每家公司的标准。这意味着很多时候您可能不同意该政策。

抱怨必须使用公司标准进行自动格式化是不专业的，最终会损害你的老板和上级对你的看法，因为他们会认为你不是一个团队合作者。无论标准格式与您想要的有多远，您都会习惯于任何标准格式，并且有一天当您成为经理时，您可以选择如何进行格式设置。与此同时，这不是你的决定（你不拥有代码库，公司拥有），你需要做你被要求做的事情。

如果您有一些关于自动格式化如何使代码更难阅读的有效示例，您可以与您的老板分享它们，但老实说，这是一场您不太可能获胜的战斗，它只会让您看起来很难尝试。

于 2009-11-04T20:03:31.407 回答
0

在 Eclipse 中启用自动格式化时我能想到的一个问题是，如果您使用源代码控制（您正在使用源代码控制，对吗？），差异将会很大，并且可能难以破译什么是真正的代码更改与格式更改。

话虽如此，拥有格式良好的代码对于编写可靠的软件至关重要。

于 2009-11-04T14:54:38.900 回答