使用空格而不是制表符进行缩进的客观原因？ [英] Objective reasons for using spaces instead of tabs for indentation?
问题描述
根据PSR-2标准，是否有客观原因使用空格代替制表符来缩进文件，有人可以提供：
Are there objective reasons for using spaces instead of tabs for indenting files as per PSR-2 standard, can someone provide:
- 事实，
- 引用，
- 特定的专业知识
PSR-2标准基于？
on which PSR-2 standard is based?
PSR-2标准的作者所想到的不只是外观和感觉，还不仅仅是基于意见的东西，而且很多人都难以理解为什么空间会更好
Authors of PSR-2 standard had in mind something more than "look and feel", something more than just opinion based thing, and lots of people have trouble understanding why spaces are better during teamwork.
根据Farsides的回答：存储库可能是PSR-中为什么存在空格的确切案例2解释为压痕工具。 PSR-2是为协助团队合作而标准开发的。行的开头的单个偶然空格-使用制表符时-在IDE中可能不可见，并且可以潜入存储库。如果几个人在同一个文件上工作，极有可能产生不必要的冲突。使用空格而不是制表符可以轻松地在眼球上捕捉到这样的意外空间，这可能是使用它们成为标准的原因。
According to Farsides' answer: repositories thing may be an exact case of why spaces are in PSR-2 explained as indentation tool. PSR-2 is standard developed to assist teamwork. Single accidental spaces at the beginning of line - when using tabs - may not be visible in the IDE and can sneak out to repository. If a couple of people work on same file it is highly possible to generate unnecessary conflicts. Using spaces instead of tabs makes it possible to easily catch such an accidental space on eyeball and this is probably a reason, why using them become a standard.
推荐答案
事实：
1。 GIT和其他版本控制系统以不同的方式对待空白
根据我的经验，我们面临着以下项目： GIT和其他版本控制系统对待不可见的空格 + TABS 有所不同，它导致行的更改，但实际上并没有受到影响。很容易注意到，何时会意外添加一个空格 + TAB =缩进在IDE中看起来相同，但是合并时，GIT会有所作为。 这会损害您有效地比较源代码管理中的修订的能力，这确实令人恐惧。当您只有个空格时，这永远不会发生。
Facts:
1. GIT and other version controls systems treat white-space differently
Based on my experience, we faced on our projects: GIT and other version controls systems treat invisible spaces + TABS differently, and it leads to changes in lines, which actually haven't been affected. It's easy not to notice, when there will accidentally added one space + TAB = indent looks the same in IDE, but GIT will make the difference when merging. It damages your ability to effectively compare revisions in source control, which is really scary. It never going to happen when you are having spaces only.
制表符宽度（空格）取决于您的环境（文本编辑器，操作系统，首选项等），但是每个地方的空间宽度都是相同的。 IDE足够聪明，可以根据您的个人喜好处理空白，但是为协作而生成的输出应该符合标准。
The tab width (in spaces) depends on your environment (text editor, OS, preferences, etc.), but the space width is the same everywhere. IDEs are smart enough to treat white spaces up to you personal taste, but the output generated for collaboration should be up to standards.
使用空格而不是制表符可以带来8.6％的较高的薪水。使用空格而不是制表符会增加2.4年的工作经验，从而带来薪水差异。 （来源： 2017年Stack Overflow开发人员调查）。
Using spaces instead of tabs is associated with an 8.6% higher salary. Using spaces instead of tabs is associated with as high a salary difference as an extra 2.4 years of experience. (source: Stack Overflow 2017 Developer Survey).
如果您项目中的每个协作者都将保持相同的编码标准-从长远来看会很好，协作会更高效，更专业，并且缩进时您重构或发展。有关此问题的研究：
If every collaborator on your project would keep the same standards on coding - it will be good in long run, collaboration is more efficient and professional, the same indent when you refactor or develop. Studies regarding that:
-
例如， Ben Shneiderman 在程序员行为的探索性实验：
当程序语句按合理的顺序安排，专家比新手能够更好地记住它们。当陈述被打乱时，专家的优势就降低了。
when program statements were arranged in a sensible order, experts were able to remember them better than novices. When statements were shuffled, the experts' superiority was reduced.
于1984年进行的一项古老研究代码完成中引用的Soloway和Ehrlich ，以及来自编程风格元素的研究：
An old 1984 study by Soloway and Ehrlich cited in Code Complete, and supported studies from The Elements of Programming Style:
我们的经验结果使这些规则成为现实：以特定的样式编写程序不仅仅是美学问题。而是以传统方式编写程序有心理基础：程序员强烈期望其他程序员会遵循这些话语规则。 如果违反了规则，那么程序员随着时间的推移所建立的期望所提供的实用程序就会被有效地取消。
Our empirical results put teeth into these rules: It is not merely a matter of aesthetics that programs should be written in a particular style. Rather there is a psychological basis for writing programs in a conventional manner: programmers have strong expectations that other programmers will follow these discourse rules. If the rules are violated, then the utility afforded by the expectations that programmers have built up over time is effectively nullified.
这篇关于使用空格而不是制表符进行缩进的客观原因？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
