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

Max*_*Max 35 c++ git coding-style indentation

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

int main()
{
....int a = 42;
....
....return a;
}
Run Code Online (Sandbox Code Playgroud)

但是,例如git会抛出警告.所以我的问题是:为什么这些标签当前的缩进不好?

我不是在寻找像"这总是这样做"的答案.让我们假设在整个项目中一致地进行缩进.

sar*_*old 47

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

diff(1)并将patch(1)空格和制表符视为重要内容.(询问任何文件Makefile.py源文件 - 它们重要!)如果你的 "空行"上面有四个空格,而我的 "空白行"上面有八个空格,那么任何在我们之间共享补丁的尝试都会因为非常微不足道而失败原因.

当然,如果你批量更改代码块的缩进,你将不得不去做一些工作,无论如何应用补丁.但是试图在看起来空白的线上追踪合并失败是痛苦的.(我已经浪费了太多的我的生活正是这样做的.是的,vim listchars可以帮助,但阅读代码listchars在所有的时间讨厌.)

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

  • +1为优秀的推理和使用"简约". (8认同)