使用空格而不是制表符进行缩进的客观原因？答案

【问题标题】：Objective reasons for using spaces instead of tabs for indentation?使用空格而不是制表符进行缩进的客观原因？
【发布时间】：2016-06-09 13:23:48
【问题描述】：

根据 PSR-2 标准使用空格而不是制表符来缩进文件是否有客观原因，有人可以提供：

事实，
参考，
专业知识

基于哪个 PSR-2 标准？

PSR-2 标准的作者考虑的不仅仅是“外观和感觉”，也不仅仅是基于意见的东西，很多人很难理解为什么在团队合作中空间更好。

接受答案的解释：

根据 Farsides 的回答：存储库可能是 PSR-2 中空格解释为缩进工具的确切情况。 PSR-2 是为协助团队合作而开发的标准。行首的单个意外空格 - 使用制表符时 - 在 IDE 中可能不可见，并且可以潜入存储库。如果几个人在同一个文件上工作，很可能会产生不必要的冲突。使用空格而不是制表符可以轻松捕捉眼球上的这种意外空格，这可能是为什么使用它们成为标准的原因。

【问题讨论】：

@deceze，不，你不对。在下面找到我的答案，这背后有具体的原因。
@Farside 是的，这是有原因的。标签的粉丝有理由支持标签。任何一方都不是“正确的”，双方都有自己决定一件事或另一件事的理由。（注意：我也支持空格，原因与您给出的相同。但您必须提供具体证据证明这是 PSR 规范中支持空格的原因，它才能成为真正的答案；您可以链接的任何会议纪要到...？）
我们在工作中正在进行同样的讨论。旧项目有制表符缩进，并且在更改我们的 IDE 配置以将制表符扩展为空格时存在一些摩擦。您可以设置选项卡的外观，但多次按退格键并不方便。只是寻找针对标签的激烈论据:(
也许您可以将您的问题重新表述为：使用空格而不是制表符来缩进文件的客观原因？因为这显然是您真正想知道的，
我编辑了这个问题，以满足 StackOverflow 的要求和最佳实践，因此它基于事实，而不是基于意见。 @deceze，greg-449，Ctx，Raidri，Alex Tartan，请重新投票。谢谢。

标签： php code-formatting psr-2

【解决方案1】：

事实：

1。 GIT 和其他版本控制系统对空白的处理方式不同

根据我的经验，我们在项目中遇到过：GIT 和其他版本控制系统 对不可见的spaces + TABS 的处理方式不同，它会导致行的变化，实际上并没有'没有受到影响。很容易注意到，当不小心添加了一个space + TAB = indent 在IDE中看起来一样，但是GIT在合并时会有所不同。 它会损害您在源代码管理中有效比较修订的能力，这真的很可怕。当您只有spaces 时，它永远不会发生。

2。消除协作者环境（编辑器、操作系统、偏好等）的差异

制表符宽度（以空格为单位）取决于您的环境（文本编辑器、操作系统、首选项等），但空格宽度在任何地方都相同。 IDE 足够聪明，可以根据您的个人喜好来处理空白，但为协作生成的输出应该符合标准。与PSR-2 states 一样，仅使用空格，而不是将空格与制表符混合，有助于避免差异、补丁、历史记录和注释问题。使用空格还可以轻松插入细粒度的子缩进以进行行间对齐。

3。使用空格的开发者比使用制表符的开发者赚更多的钱

使用空格而不是制表符与 8.6% 更高的薪水相关。使用空格而不是制表符与额外 2.4 年经验的工资差异一样高。（来源：Stack Overflow 2017 Developer Survey）。

4。关于编码风格重要性的大量研究

如果您项目中的每个协作者都在编码方面保持相同的标准 - 从长远来看，这将是一件好事，协作会更加高效和专业，重构或开发时的缩进量相同。相关研究：

例如，Ben Shneiderman 在Exploratory experiments in programmer behavior 中证实了这一点：

当程序语句以合理的顺序排列时，专家能够比新手更好地记住它们。当陈述被洗牌时，专家的优势就降低了。
Soloway 和 Ehrlich 于 1984 年进行的一项旧研究在Code Complete 中引用，并支持来自The Elements of Programming Style 的研究：

我们的实证结果证实了这些规则：程序应该以特定的风格编写不仅仅是美学问题。相反，以传统方式编写程序有一个心理学基础: 程序员强烈期望其他程序员会遵循这些话语规则。 如果违反了规则，那么程序员随着时间的推移所建立的期望所提供的实用程序实际上无效。

【讨论】：

但这是特定于环境的“外观”，而不是实际情况。单个选项卡仍然是单个选项卡，它不会神奇地更改为 4 或 2 个空格。如果我希望我的 IDE 将选项卡显示为 120px 宽的块，我可以这样做。而且我无法更改空间的宽度..
@yergo 再说一遍：请不要重新讨论这个论点。没有赢家。
我认为这个答案解决了一个不同的问题（“为什么要设置编码标准”）。此外，“中和合作者环境中的差异”点实际上不是空间缺陷吗？这就像是在争论不能改变字体大小是一种优势。
好消息，我今天将开始使用空间并通知管理层我的加薪情况
第一个要点没有为空格提供令人信服的理由。它指出了一致缩进的重要性，这是普遍接受的。没有什么可以解释为什么 “总是使用空格” 优于 “总是使用制表符”。同样，最后一个要点没有提供任何事实证据，为什么空格优于制表符。第三个要点实际上只是对相关性的观察，没有因果关系的陈述。

【解决方案2】：

许多人认为标准也优于公制。仅仅因为许多人或大多数人的想法，并不意味着它更好或更正确。

举例：制表符显然比空格好:)

【讨论】：

您的答案可以通过额外的支持信息得到改进。请edit 添加更多详细信息，例如引用或文档，以便其他人可以确认您的答案是正确的。你可以找到更多关于如何写好答案的信息in the help center。
制表符失败的一个领域是对齐长字符串和 cmets。我见过的一些 cmets 在与参数对齐时也读得更好，这肯定会在不同的选项卡大小上错位。

【解决方案3】：

补充事实：

项目中使用空格的正则表达式搜索表达式与项目中使用制表符或混合制表符和空格的项目不同

【讨论】：