yer*_*rgo 9 php code-formatting psr-2
根据PSR-2标准,是否有客观原因使用空格而不是制表符来缩进文件,有人可以提供:
PSR-2标准的基础？
PSR-2标准的作者想到的不仅仅是"外观和感觉",不仅仅是基于观点的东西,很多人都难以理解为什么在团队合作中空间更好.
根据Farsides的回答:存储库事物可能是为什么空间在PSR-2中被解释为缩进工具的确切情况.PSR-2是为协助团队合作而开发的标准.行开头处的单个意外空间 - 使用制表符时 - 可能在IDE中不可见,并且可能会潜入存储库.如果有几个人在同一个文件上工作,很可能会产生不必要的冲突.使用空格而不是标签可以轻松捕捉到眼球上的这种意外空间,这可能是一个原因,为什么使用它们成为标准.
Far*_*ide 15
根据我的经验,我们面对的是我们的项目:GIT和其他版本控制系统对待不可见spaces+ TABS不同,它会导致线条的变化,实际上并没有受到影响.很容易没有注意到,当意外添加一个space+ TAB=缩进在IDE中看起来相同时,但GIT将在合并时产生差异.它会损害您有效比较源代码管理中的修订版本的能力,这实际上是非常可怕的.当你spaces只有你时,它永远不会发生.
标签宽度(在空格中)取决于您的环境(文本编辑器,操作系统,首选项等),但空间宽度在任何地方都是相同的.IDE非常智能,可以根据您的个人喜好处理白色空间,但协作产生的输出应符合标准.
使用空格而不是制表符与工资提高 8.6%相关联.使用空格而不是制表符与薪水差异相关,与额外的2.4年经验相关.(来源:Stack Overflow 2017开发者调查).
如果你的项目中的每个合作者都会在编码上保持相同的标准 - 从长远来看,这将是好的,协作更有效率和专业性,当你重构或开发时,同样的缩进.研究:
例如,Ben Shneiderman 在程序员行为的探索性实验中证实了这一点:
当程序陈述以合理的顺序排列时,专家能够比新手更好地记住它们.当声明改组时,专家的优势得以降低.
Soloway和Ehrlich在1984年的一项旧研究中引用了Code Complete,并支持编程风格元素的研究:
我们的实证结果为这些规则注入了灵感:程序应该以特定的方式编写,这不仅仅是美学的问题.相反,以传统方式编写程序存在心理基础:程序员强烈期望其他程序员将遵循这些话语规则.如果规则被违反,那么程序员随着时间推移建立的期望所提供的效用实际上是无效的.
Zwy*_*wyx 14
该线程很旧，但仍然显示在搜索结果中，并且不仅适用于 PHP 查询。我认为它缺乏关于可访问性的现代思想。
\n接受的答案中的事实很清楚：对于外观一致的代码，空格是最好的。
\n然而，与你一起工作的人之间是否也保持一致？
\n情况可能并非如此：有些人可能有视力障碍。
\n在一个开源项目中，人们甚至可能不知道与他们一起工作的人员有多“一致”。
\n有些需要如此大的字体大小，能够将制表符宽度设置为 1 是一件大事。（我是近视眼，虽然我除了戴眼镜之外没有特殊需求，但我可以理解它对其他人有多么有用）。
\n在使用空格的项目上工作了多年，以及使用制表符的项目多年之后，对我来说显而易见的是，对于大多数开发人员来说，制表符或空格不会改变任何东西。我们很容易适应其中一种选择。
\n唯一重要的是有特殊需要的人。对于他们来说，标签更好。难道这件事不应该已经板上钉钉了吗？
\n如今更是如此，因为许多语言现在都有很好的工具来自动格式化我们的代码。如果自动格式化程序可用于某种语言，那么应优先考虑使用它。不用考虑缩进或格式真是太棒了。
\n使用选项卡，代码在每个人的屏幕上看起来将不再一致，但另一件事将变得一致：为每个人提供良好的体验。
\n正是由于这个原因，网络引入了媒体查询，例如prefers-color-scheme和prefers-contrast。我们希望提高网站的可访问性；源代码值得同样的。
因此，我的建议是设置项目设置来修复开发人员不必处理的操作系统之间的差异，并设置一些首选项，例如修剪尾随空格。
\n就是这样。不要设置制表符宽度，这是用户设置。
\n强制选项卡宽度就像为项目中的每个人强制使用明亮的高对比度主题一样。
\n例如，这是一个.editorconfig文件：
# https://editorconfig.org\n\n[*]\ncharset = utf-8\nend_of_line = lf\nindent_style = "tab"\ntrim_trailing_whitespace = true\ninsert_final_newline = true\n还有一个.vscode/settings.json文件：
{\n "files.encoding": "utf8",\n "files.eol": "\\n",\n "files.trimTrailingWhitespace": true,\n "files.insertFinalNewline": true,\n "files.trimFinalNewlines": true,\n "editor.insertSpaces": false,\n "editor.defaultFormatter": "esbenp.prettier-vscode",\n}\n（此外，已接受的答案中的第 3 点 \xe2\x80\x94“赚更多钱”\xe2\x80\x94 可能会产生误导。使用空间的开发人员可能只是因为年龄较大而赚更多钱（所以有旧习惯）。年轻的开发人员（工资较少）可能会回答说他们使用制表符，因为他们在缩进时按 Tab 键。还有更多，请参阅原始帖子下面的评论。）
\nTL;DR：我建议使用制表符并且不要强制其宽度（如果可能的话，对其他所有内容使用自动格式化程序）。当然，如果您使用的项目/语言由于技术原因不允许这样做，则这不适用。
\n对于现代 IDE，没有充分的理由在制表符上使用空格进行缩进。
到目前为止，最常见的空间原因是：
不同计算机和开发人员之间的代码一致性。
谁想要这个？为什么这很重要或值得期待？
似乎没有人知道答案。我不介意我是否看到其他开发人员的屏幕，他们喜欢缩进 2、3 或 4 个空格宽度（随着远程工作的不断增长，情况会越来越少）。现代 IDE 可以显示用户喜欢的任何宽度的选项卡，为什么要强制它们呢？每个开发人员都知道如何高效且舒适。
我们不强迫人们的 IDE、主题、字体、文本颜色或语法突出显示方案，那么为什么缩进应该不同呢？
单个Tab字符意味着将缩进级别增加 1，简单、优雅、简单。
混合制表符和空格是不好的。
完全同意。不要混合。制表符非常适合缩进。另一方面，制表符对于代码对齐来说很糟糕（如果这是你的事），而空格则非常适合。
有人可能会不小心留下与选项卡混合的杂散空间而没有注意到它。
在 2023 年，没有任何借口不使用代码短绒、git 挂钩和任何其他工具来防止我们意外搞砸并将格式错误的代码推送到共享代码库。