源代码中的TAB字符是否不正确

Is the TAB character bad in source code?

本文关键字:是否 不正确 字符 TAB 源代码      更新时间:2023-09-26

我对Zend和PEAR PHP编码标准都很熟悉,而且从我之前的两位雇主那里,代码库中不允许使用TAB字符,声称它可能被构建脚本或其他东西误解了(我真的记不清确切的原因了)。我们都设置了IDE,将TAB分解为4个空格。

我已经习惯了,但现在我的新雇主坚持使用TAB,而不是空格来进行缩进。我想我真的不应该在乎,因为当我点击TAB键时,我可以告诉PHP Storm只使用TAB字符,但是,我确实这样做了。我想要空格,我想要一个有效的论据来解释为什么空格比TAB更好。

因此,除了个人偏好之外,我的问题是,是否有正当理由避免在我们的代码库中使用TAB?

请记住,此编码标准适用于PHP和JavaScript。

选项卡更好

  • 更清晰让读者了解每段代码的级别;空格可能不明确,尤其是当不清楚您使用的是2空格制表符还是4空格制表符时
  • 概念上更有意义。缩进时,需要的是制表符而不是空格。文档应该表示您在键盘上所做的操作,而不是在文档设置中
  • 标签不能与扩展代码行中的空格混淆。特别是当单词扭曲被启用时,一系列被包装的单词中可能会有一个空格。这显然会使读者感到困惑。这会减慢配对编程的速度
  • 选项卡是一个特殊字符。当在IDE上启用特殊字符的查看时,可以更容易地识别级别

请注意:在Windows、Mac或Linux上,只需按下CTRL+ALT+L,您就可以使用JetBrains的任何编辑器(例如PHPStorm、RubyIDE、ReSharper、IntelliJIDEA等)在选项卡和空格之间轻松切换。

有正当理由避免在我们的代码库中使用TAB吗?

我咨询过许多公司,从未遇到过没有的代码库在各种源文件中混合了制表符和空格,也从未遇到过问题

首选?当然

是否合法,是否符合既定规则、原则或标准?编号

编辑

我真正想知道的是,如果TAB没有什么问题,为什么Zend和PEAR会明确表示他们不被允许吗?

因为这是他们的偏好。他们希望遵循一种惯例来保持一致性(以及命名和大括号样式)。没什么了。

空格比选项卡更好,因为不同的编辑器和查看器,或者不同的编辑器设置,可能会导致选项卡显示不同。如果编程语言对制表符和空格一视同仁,那么这就是避免制表符的唯一合理原因。如果某个工具卡在选项卡上,那么从语言的角度来看,该工具就是坏的。

即使团队中的每个人都将他们的编辑器设置为将选项卡视为四个空格,当您必须在某个工具中打开源代码时,您也会得到不同的显示。

最需要担心的是始终使用相同的缩进方案时的一致性-混淆标签和空格是活地狱,比纯标签或纯空格更糟糕因此,如果项目的其余部分使用选项卡,您也应该使用它们

无论如何,在标签与空间之间并没有一个明显的赢家。Space的支持者表示,对所有内容只使用空格是一条更简单的规则,而Tabs的支持者则表示,使用制表符进行缩进和空格进行对齐可以让不同的开发人员更舒适地显示制表符宽度。

最后,制表符与空格是不应该是一个出价交易。我似乎唯一一次有人认为其中一种替代方案比另一种要好,那就是在对缩进敏感的语言中,比如Python或Haskell。在这些混合的选项卡和空间中,可以以难以看到的方式更改程序语义,而不仅仅是让源代码看起来很奇怪。

自从我的第一个CS类以来,制表符一直是禁忌。原因是,选项卡基本上就像变量。不同的IDE可以将TAB定义为不同数量的空间。从VisualStudio/NetBeans/DevC++的角度来看,所有这些都有能力根据所需空间的数量来更改TAB的"定义"。所以,如果你定义了4个空格,你就不可能知道我的IDE是说3个空格还是5个空格。因此,如果有人碰巧使用基于空间的缩进样式,而其他人使用TABS,那么格式可能会被打乱。然而,作为一个反点,如果"标准"是始终使用制表符,那么这真的无关紧要,因为无论定义的空格数量如何,格式都会显示相同但是只需要一个人使用一个空格,格式可能看起来很糟糕,而且非常令人困惑。使用空格时不会发生这种情况。此外,如果您不想在函数/方法等之间使用相同的间距,会发生什么?如果你喜欢在某些情况下使用4个空格,而在其他情况下只使用2个空格,该怎么办?

我见过解析源代码、生成文档甚至其他代码的构建脚本。这类脚本通常取决于代码的预期格式,通常这意味着要么使用空格(有时使用制表符)。也许可以通过检查选项卡空间来修改这些脚本,使其更加健壮,但您经常会被现有的内容所困扰。在这种环境中,一致的格式变得更加重要。