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

我所知道的每个自由/开放源码软件项目都有规则来防止代码中的尾随空格。但是我认为继续当前的缩进是非常自然的：

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

但是git反正会抛出警告。所以我的问题是：为什么当前缩进内的那些标签不好？

我不是在寻找像“总是这样做”的答案。让我们假设在整个项目中缩进是一致的。

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

diff(1)和patch(1)将空格和制表符视为重要内容。（询问任何Makefile或.py源文件 – 它们很重要！）如果你的 “空白行”上有四个空格，而我的 “空白行”上有八个空格，任何试图在我们之间共享补丁的尝试都将失败为非常平凡的原因。

当然，如果你批量改变一段代码的缩进，你将不得不去做一些工作来补丁。但是试图追踪看起来空白的合并失败是很痛苦的 。（我浪费了太多的时间来做这件事，是的， vim listchars可以提供帮助，但是随时用listchars读代码也是很烦人的。）

所以人们在没有尾随的空白处标准化。从存储的angular度来看，十几个丢失的字节可能没有什么意义，但它确实使得修补程序更容易。我们或许也可以按照您的build议来标准化添加尾随空白，并且同样高兴，但是我们也可以尽可能地简化标准化。

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

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

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