继承代码：格式化还是不格式化？ [关闭]

Posted 2023-02-21

【中文标题】继承代码：格式化还是不格式化？ [关闭]

【英文标题】：Inherited code: To format or not to format? [closed]

【发布时间】：2010-12-13 01:13:22

【问题描述】：

我们的团队最近继承了极其杂乱无章的代码。

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

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

你有什么意见？

【问题讨论】：

也许您可以向我们提供一些您不会看到自动格式化的代码示例...

很抱歉，我不能，因为它完全是专有的，并且是我们产品业务逻辑的核心:(

【参考方案1】：

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

【讨论】：

基本上不是一个坏主意，但我不是我的团队负责人，他希望永远继续自动格式化......

是的，我认为最初使用自动格式化是一个好主意，可以控制代码库，然后在没有它的情况下继续进行，以便人工判断可以接管。

【参考方案2】：

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

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

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

【讨论】：

感谢您的警告 - 但我和我的团队负责人关系很好。我只是认为这是一个有趣的困境，并希望听到我工作的公司之外的其他人的经验。

【参考方案3】：

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

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

【参考方案4】：

我和你的团队负责人一起做这个，我有两个建议给你：

将每个文件保存一次 更改是带有 a 的格式 提交反映该信息的消息 这一切都改变了，然后去 返回并制作您的实际代码 变化。这将为您节省很多 你需要区分的时间 变化。格式修订将 几乎每一行代码 改变了，所以它实际上会 不可能找到真正的改变 相同的版本。

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

【参考方案5】：

格式化代码非常重要：

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

更容易

【讨论】：

你说的都是真的 - 但我认为不需要自动格式化......

不需要使用格式化程序，但使用自动格式化程序比手动格式化要容易得多。

【参考方案6】：

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

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

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

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

附：最后的陈述完全是轶事，因为我没有指标可以支持它。

【参考方案7】：

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

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

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

【讨论】：

在这种情况下，您需要的唯一规则是“保留您编辑的文件的样式”，而不是“团队中的每个人都必须使用样式 X”

【参考方案8】：

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

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

我建议你也考虑一下。

【参考方案9】：

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

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

【讨论】：

我们正在使用源代码管理，如果我们希望在自动格式化后签入所有文件而不进行任何其他人为更改，我们可以这样做。

【参考方案10】：

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

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

【讨论】：

eclipse 格式化程序可以配置为高度...

@Christian：那么您使用的是较旧的 Eclipse 版本，或者存在监督设置。 Eclipse 自古以来就在这里用空格格式化。如果我没记错的话，您在 3 个位置设置为使用空格而不是制表符。祝你好运。

【参考方案11】：

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

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

【参考方案12】：

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

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

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

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

将被重新格式化：

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

表明if 语句中的第二行不是。

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

【讨论】：

但是我能不能不强制执行一个不那么严格的政策，而不是像计算机一样严格？

问题是：打破格式风格有什么好处吗？如果没有，为什么不使用自动格式化程序？

易读性有时是面向上下文的...

我完全不同意，来自痛苦的经历。我已经看到几个非常大的代码库经过专业格式化，但却以非常复杂的方式解决了问题。

您的答案不是关于自动格式化，而是关于一般的格式化。还有其他选项可以使格式同质化。 CheckStyle 插件会使您的示例中的错误更加引人注目，因为它会创建警告而不是重新格式化它。