为什么空行中的缩进不好？

Question

我所知道的每个FOSS项目都有针对代码中尾随空格的规则。但我认为继续下一行的当前缩进是很自然的：

int main()
{
....int a = 42;
....
....return a;
}

但是，例如git会抛出警告。所以我的问题是：为什么里面的 当前缩进不好？

我不是在寻找“总是这样做”的答案。让我们假设缩进在整个项目中始终完成。

Answer 1

可能是因为将补丁与无用的空格合并比应该更难。

diff(1)和patch(1)将空格和标签视为重要内容。 （询问任何Makefile或.py源文件 - 他们 重要！）如果您的“空行”上有四个空格，并且我的“空行”上面有八个空格，任何在我们之间共享补丁的尝试都会因为非常重要的原因而失败。

当然，如果你批量更改代码块的缩进，你将不得不去做一些工作，无论如何应用 。但是，尝试在看起来空白的行上追踪合并失败痛苦。 （我浪费了太多的生命就是这样。是的，vim listchars可以提供帮助，但一直使用listchars阅读代码也讨厌。）

所以人们标准化没有尾随空格。从存储的角度来看，在这里或那里担心十几个丢失的字节可能没有多大意义，但它真的使得合并补丁更容易。我们可能就像你建议的那样标准化添加尾随空格，并且同样高兴，但我们也可以尽可能地标准化这种方法。

Answer 2

对于习惯使用段落导航来跳过代码的vi用户来说，这也很粗鲁。有时我在vi时这样做，当我跳过几个函数时非常令人惊讶，因为隐形字符表示这实际上是前一段的一部分。

Answer 3

我认为它归结为“代码中没有多余的隐藏惊喜字节”。

正如@sarnold指出的那样，多余的惊喜字节会使修补和差异变得不必要地混乱。