代码格式化：排列类似的行可以吗？ [关闭]答案

【问题标题】：Code formatting: is lining up similar lines ok? [closed]代码格式化：排列类似的行可以吗？ [关闭]
【发布时间】：2010-09-11 05:53:14
【问题描述】：

我最近发现我们公司有一套编码指南（隐藏在文档管理系统中，没有人可以找到它）。它通常看起来很明智，并且远离通常的宗教战争，即在哪里放置 '{' 以及是否使用硬制表符。但是，它确实建议“行不应包含嵌入的多个空格”。这意味着不要做这种事情：

foo    = 1;
foobar = 2;
bar    = 3;

或者这个：

if      ( test_one    ) return 1;
else if ( longer_test ) return 2;
else if ( shorter     ) return 3;
else                    return 4;

或者这个：

thing foo_table[] =
{
  { "aaaaa", 0 },
  { "aa",    1 },
  // ...
}

这样做的理由是，对一行的更改通常需要对每一行进行编辑。这使得改变变得更加努力，并且更难理解差异。

我很伤心。一方面，像这样排列可以使重复的代码更容易阅读。另一方面，它确实使差异更难阅读。

您对此有何看法？

【问题讨论】：

第一个和第三个例子很好，但我认为第二个可能需要将它分成几行。

标签： formatting coding-style alignment code-readability human-readable

【解决方案1】：

对于一个好的编辑器，他们的观点是不正确的。 :)

（参见 vim 的“可视块”模式。）

P.S.：好的，你仍然需要更改每一行，但它又快又简单。

【讨论】：

【解决方案2】：

我很伤心。一方面，排队这样可以使重复的代码更容易阅读。在另一手，它确实使差异更难阅读。

好吧，既然使代码易于理解比使差异易于理解更重要，你不应该被撕裂。

恕我直言，排列相似的行确实大大提高了可读性。此外，它允许使用允许垂直选择的编辑器更轻松地进行剪切和粘贴。

【讨论】：

折衷方案是不理会现有代码，但允许重新格式化新代码或已经“触及”的代码。还有其他更改，例如按字母顺序或数字顺序重新排序列表，争论可能适用。

【解决方案3】：

2008：由于我每天监督源代码的合并，...我只能反对它。

这很漂亮，但是如果您定期进行合并，“更易于阅读”的好处很快就会远远小于合并该代码所涉及的工作量。

由于这种格式不能以简单的方式自动化，第一个不遵循它的开发人员将触发非平凡的合并。

不要忘记在源代码合并中，不能让 diff 工具忽略空格 :
否则，"" 和 " " 在 diff 过程中看起来是一样的，这意味着不需要合并...编译器（以及在字符串双引号之间添加空格的编码器）不会同意这一点！

2020：如the comments Marco 所述

大多数代码合并应该能够处理忽略空格并且对齐等号现在是大多数 IDE 中的自动格式选项。

我仍然更喜欢带有自己格式选项的语言，例如 Go 及其 gofmt command。
甚至Rust 现在也有它的rustfmt。

【讨论】：

不是更糟吗？任何需要重新排列的编辑（实际上这似乎更常见于您想要的）都会为您提供一个差异，其中整个代码块都会发生变化。这将意味着立即进行非平凡的合并。
终于！我开始认为我是唯一一个这样想的人；）即使@Agoston Horvath 建议忽略空格，也不是版本控制工具中使用的每个工具都能做到这一点，而且确实变得“比这更糟糕”
如果源代码控制系统不能忽略空格，这难道不是一个失败吗？
@DisgruntledGoat：我同意这应该在版本系统中处理，但这必须意味着版本系统知道代码的含义。
请注意，上面的答案仍然是 Google 上的第一个热门答案。它是在 2008 年编写的，大多数代码合并应该能够处理忽略空格，并且对齐等于现在是大多数 IDE 中的自动格式选项。

【解决方案4】：

我们在多个合同的差异方面遇到了类似的问题......我们发现标签最适合每个人。设置您的编辑器以维护选项卡，每个开发人员也可以选择自己的选项卡长度。

示例：我喜欢 2 个空格制表符，以使左侧的代码非常紧凑，但默认值为 4，因此尽管缩进等在我们的各个屏幕上看起来非常不同，但差异是相同的，并且没有'不会导致源代码管理问题。

【讨论】：

我不相信可以用标签进行这种排列。至少，如果您希望代码仍然与不同的制表符宽度对齐，则不会。
哦，经过仔细检查，我意识到我对没有在 Tabs vs. Spaces 上发音的指导方针是错误的：它几乎说永远不要使用硬制表符 :)

【解决方案5】：

我从不这样做。正如您所说，有时需要修改每一行以调整间距。在某些情况下（例如上面的条件句），如果您取消间距并将块放在与条件句不同的行上，它将完全可读并且更容易维护。

此外，如果您的编辑器中有不错的语法高亮显示，那么这种间距实际上是不必要的。

【讨论】：

【解决方案6】：

就我个人而言，我更喜欢以稍微难以阅读的差异为代价来提高代码的可读性。在我看来，从长远来看，对代码可维护性的改进——尤其是在开发人员来来去去的时候——是值得权衡的。

【讨论】：

【解决方案7】：

这正是好主给出的制表符的原因——在行的中间添加一个字符不会弄乱对齐。

【讨论】：

另一方面，强烈建议使用空格而不是制表符。
我倾向于同意，因为很难手动正确缩进制表符，而且我还没有遇到一个总是能正确缩进的编辑器。然而，这是一个相当有争议的观点。
制表符很好，但有 1/8 或 2/8 的机会（假设制表符大小为 8）会扭曲列化（此处考虑 git diff，尽管可以创建一个自定义 diff 命令，它像往常一样生成 diff 后，智能地用空格替换选项卡作为后过滤步骤）。

【解决方案8】：

我喜欢第一个和最后一个，但不太喜欢中间。

【讨论】：

【解决方案9】：

如果您打算使用自动代码标准验证（即 CheckStyle、ReShaper 或类似的东西），这些额外的空间将使编写和执行规则变得非常困难

【讨论】：

由于似乎没有人知道我们有一个标准，这在我们的案例中似乎不太可能:)
这正是您需要自动代码标准验证的原因。开始使用它

【解决方案10】：

史蒂夫·麦康奈尔（Steve McConnell）在非常有用的 Code Complete 中对此进行了一些讨论。如果您没有这本开创性书籍的副本，请帮自己一个忙，买一本。无论如何，讨论在第一版的第 426 和 427 页上，这是我手头的版本。

编辑：

McConnell 建议在一组赋值语句中对齐等号，以表明它们是相关的。他还告诫不要在一组作业中对齐所有等号，因为它可以在视觉上暗示没有关系的地方。例如，这将是适当的：

Employee.Name  = "Andrew Nelson"
Employee.Bdate = "1/1/56"
Employee.Rank  = "Senator"
CurrentEmployeeRecord = 0

For CurrentEmployeeRecord From LBound(EmployeeArray) To UBound(EmployeeArray) 
. . .

虽然这不会

Employee.Name         = "Andrew Nelson"
Employee.Bdate        = "1/1/56"
Employee.Rank         = "Senator"
CurrentEmployeeRecord = 0

For CurrentEmployeeRecord From LBound(EmployeeArray) To UBound(EmployeeArray) 
. . .

我相信差异是显而易见的。还有一些关于对齐延续线的讨论。

【讨论】：

也许你可以提供一个简短的报价或总结讨论，以使答案更有帮助。
McConnell 在随后的 Code Complete 修订版中对此建议做了 180 分。他在第二次修订中的建议是：不要对齐赋值语句的右侧。他承认这种对齐方式略微提高了可读性和可理解性，但这种风格的巨大维护成本并不能证明这种轻微的提高是合理的。
@DavidHammen 很高兴您添加了该评论；我完全不知道他在这一点上改变了他的建议。
麦康奈尔的书（第二版）中的相关页面是第758页。

【解决方案11】：

您可以将差异工具设置为忽略空格（GNU 差异：-w）。这样，您的差异将跳过这些行，只显示真正的变化。很方便！

【讨论】：

版本控制工具中使用的 diff 工具并不总是可行的。这意味着这个 diff 工具知道 String 中的空格（不能忽略）。我的旧 Winmerge 2.6.14 将考虑（使用该设置）“”和“”是相同的......Java 编译器会不同意；）

【解决方案12】：

我从不这样做，我总是建议不要这样做。我不在乎差异更难阅读。我确实很在意首先要花时间来做这件事，而且每当必须重新对齐线条时，都需要额外的时间。编辑具有这种格式风格的代码令人恼火，因为它通常会耗费大量时间，我最终会花费更多时间来格式化而不是进行真正的更改。

我也质疑可读性的好处。此格式样式在文件中创建列。但是，我们不阅读列样式，从上到下。我们从左到右阅读。这些列分散了标准阅读风格的注意力，并将视线拉向下方。如果它们没有完全对齐，这些列也会变得非常难看。这适用于无关的空白，也适用于多个（可能不相关的）列组，这些列组具有不同的间距，但在文件中一个接一个地落下。

顺便说一句，我发现您的编码标准没有指定制表符或大括号的位置真的很奇怪。与使用（或不使用）列式格式相比，混合使用不同的制表符样式和大括号位置会损害可读性。

【讨论】：

我认为它有一条关于在文件/模块/项目中坚持一种风格的元规则。无论如何，几乎没有人知道这个文件的存在:)
当公司没有强制执行的全球规则时，我总是觉得很奇怪。允许人们使用他们想要的任何样式意味着将代码从一个项目移动到另一个项目会成为问题。
如果在另一个项目中有一组写得很好的函数，但是以完全不同的风格编写，那么将它们放到我的项目中是有问题的。我要么必须混合样式，要么浪费时间重新格式化代码。
调用漂亮打印机需要多长时间？

【解决方案13】：

我尝试遵循两个准则：

尽可能使用制表符代替空格，以尽量减少重新格式化的需要。
如果您担心对修订控制的影响，请先进行功能性更改，签入，然后仅进行外观性更改。 p>

如果在“修饰”更改中引入了错误，则允许公开鞭打。 :-)

2020 年 4 月 19 日更新： 天哪，这十几年的变化！如果我今天要回答这个问题，可能是这样的：“请您的编辑器为您格式化代码和/或告诉您的差异工具在您进行外观更改时忽略空格。

今天，当我检查代码的可读性并认为通过不同的格式设置可以提高清晰度时，我总是以“......除非编辑器自动这样做。不要与你的工具对抗。他们总是赢。”

【讨论】：

我打算推荐这个。我通常反过来做。仅进行第一次外观更改。让我对代码有点熟悉，并且更容易阅读。然后功能发生变化。

【解决方案14】：

我的立场是这是一个编辑器问题：虽然我们使用花哨的工具查看网页并在文字处理器中编写文本，但我们的代码编辑器仍然停留在 ASCII 时代。它们尽可能地愚蠢，然后，我们尝试通过编写花哨的代码格式化程序来克服编辑器的限制。

根本原因是您的编译器不能忽略代码中的格式化语句“嘿，这是一张表”，并且 IDE 不能即时创建源代码的视觉上令人愉悦的表示（即实际上没有改变代码的一个字节）。

一种解决方案是使用制表符，但我们的编辑器无法自动对齐连续行中的制表符（这会使很多事情变得容易得多）。为了增加侮辱性的伤害，如果您弄乱了标签宽度（基本上是任何东西！= 8），您可以阅读 your 源代码，但不能阅读其他任何人的代码，例如随附的示例代码您使用的库。最后，我们的差异工具没有选项“忽略空格，除非它很重要”，并且编译器也无法生成差异。

Eclipse 至少可以以表格方式格式化赋值，这将使大量全局常量更具可读性。但这只是沙漠中的一滴水。

【讨论】：

这是一个好主意，但我不确定如果不以只能在一个特定环境中编辑的源代码结束它是否可以实现。我认为 ASCII 的最小公分母特性是一个很大的优势。
我认为是时候上一层楼了。如果我们有像样的 XML 编辑器（想想下一代 HTML 或接近当今文字处理器可以做的事情），很多事情就会突然变得可能：代码过滤和轻松生成、漂亮的显示等等。