为什么 Python pep-8强烈建议缩进使用空格而不是制表符？

制表符的问题在于它们是不可见的，人们永远无法就制表符的宽度达成一致。当你混合使用制表符和空格，并且在 Python 之外的地方设置制表符时(每8个空格使用制表符) ，你会看到代码的布局与 Python 看到的不同。由于布局决定了块，因此您将看到不同的逻辑。会导致细微的病菌。

如果您坚持不使用 PEP 8并使用制表符——或者更糟糕，混合使用制表符和空格——至少总是使用’-tt’参数运行 python，这使得 前后矛盾缩进(有时是制表符，有时是相同缩进级别的空格)成为一个错误。此外，如果可能的话，设置您的编辑器以不同的方式显示选项卡。但实际上，最好的方法是不使用制表符，句号。

制表符的另一个问题是如何在打印输出中表示它们。我相信大多数打印机会把标签页解释为8个空格。

有了空间，毫无疑问，一切都会按照作者的意图排列。

我所知道的空格优于制表符的最重要的优点是，许多程序员和项目使用一定数量的列作为源代码，如果有人将制表符设置为2个空格提交更改，而项目使用4个空格作为制表符，那么对于其他人的编辑器窗口来说，长行将太长。我同意使用制表符更容易，但我认为使用空格更容易进行协作，这在 Python 这样的大型开源项目中很重要。

由于 python 依赖缩进来识别程序结构，因此需要一种明确的识别方法。这就是选择空格或制表符的原因。

然而，python 也有一个强大的理念，即只有一种方法来做事情，因此应该有一个正式的建议，一种方法来做缩进。

空格和制表符都对编辑器处理缩进提出了独特的挑战。不同编辑器甚至用户设置对选项卡本身的处理并不统一。由于空格是不可配置的，因此它们提出了更合乎逻辑的选择，因为它们保证结果看起来处处相同。

您可以有您的蛋糕和吃它。设置您的编辑器扩展到空格自动标签。

(那就是 Vim 中的 :set expandtab。)

空格的原因是制表符是可选的。空格实际上是标点符号的最小公分母。

每个像样的文本编辑器都有一个“用空格替换制表符”，很多人都使用这个功能，但并不总是如此。

虽然有些文本编辑器可能会用制表符替换一组空格，但这种情况真的很少见。

底线.空格不会出错的。你的 也许吧出错与制表符。所以不要使用标签，减少出错的风险。

这个问题的答案已经在《人民教育报》中给出了[编辑: 这篇文章已经在 二零一三年中被编辑掉了] ，我引用如下:

最受欢迎的缩进 Python 的方式是只使用空格。

你还需要什么其他的潜在原因？

说得不那么直白: 再考虑一下第一段中所述的人道主义行动计划的范围:

本文档给出了 Python 代码的编码约定，这些代码包含主 Python 发行版中的标准库。

其目的是使 所有进入正式的 Python 发行版的代码始终如一地格式化(我希望我们可以同意，这是一个普遍的好东西)。

由于空格和制表符之间的选择对于个人程序员来说是 a)实际上是一个品味问题，b)很容易通过技术手段(编辑器，转换脚本等)来处理，有一个清晰的方法来结束所有的讨论: 选择一个。

圭多才是那个可以选择的人。他甚至不需要给出理由，但他仍然通过参考实证数据做到了这一点。

对于所有其他目的，您可以将这个 PEP 作为一个建议，或者您可以忽略它——您的选择，或者您的团队，或者您的团队领导。

但是如果我可以给你一个建议的话: 不要把它们混合在一起; ——[ ed: 不再可以选择混合制表符和空格。]

这个问题的答案是: PEP-8想要提出一个建议，并且已经决定，由于空格更受欢迎，它将强烈推荐空格而不是制表符。

关于 PEP-8的注释

我觉得我应该尝试一下和空间打交道。在我的编辑器中，我配置了一个文件类型来专门使用空格，所以如果我按制表符，它会插入4个空格。如果我按选项卡太多次，我必须删除空格！啊！删除的内容是制表符的四倍！我的编辑器不能告诉我，我使用4个空格缩进(尽管 AN 编辑器可能可以做到这一点) ，并显然坚持删除一个空格的时间。

缩进的主要问题出现在混合使用制表符和空格时。显然，这并不能告诉你应该选择哪一个，但这是一个很好的理由来推荐一个，即使你通过抛硬币来选择。

然而，恕我直言，有几个次要的理由支持空格而不是制表符:

• 不同的工具。有时代码会在程序员的编辑器之外显示。张贴在新闻组或论坛上。在这里，空格通常比制表符做得更好——所有地方的空格都会被破坏，制表符也是如此，但反之则不然。

• 程序员以不同的方式看待源代码。这是非常主观的——要么是标签的主要好处，要么是避免使用标签的理由，这取决于你站在哪一边。从好的方面来说，开发人员可以使用他们喜欢的缩进来查看源代码，所以喜欢2空间缩进的开发人员可以与8空间的开发人员在同一个源代码上工作，并且仍然可以看到他们喜欢的缩进。不利的一面是，这会产生一些反响——有些人喜欢8-space，因为它会给出非常明显的反馈，表明他们嵌套得太深了——他们可能会看到2-indenter 检入的代码不断包装到他们的编辑器中。让每个开发人员都以相同的方式看待代码会导致更加一致的 wt 行长，其他方面也很重要。

• 连续行缩进。有时，您想缩进一行，以表明它是从前一行进行的。例如。

  def foo():
  x = some_function_with_lots_of_args(foo, bar, baz,
  xyzzy, blah)
  

  如果使用制表符，那么在编辑器中使用不同制表符的人就无法在不混合空格和制表符的情况下对其进行对齐。这实际上扼杀了上述好处。译注:

显然，这是一个严重的宗教问题，而编程正受到这个问题的困扰。最重要的问题是，我们应该选择一个——即使它不是你喜欢的那个。有时候我认为重大压痕的最大好处是至少我们避免了支撑位置的火焰战。

同样值得一读的还有 Jamie Zawinski 关于这个问题的 这个文章。

返回文章页面

当(人们)阅读代码时，当他们写完新代码时，他们关心当一个新范围(sexpr 或其他)打开时，代码倾向于缩进的屏幕列有多少... ..。

我的观点是，解决技术问题的最好方法是要求 ASCII # 9 TAB 字符永远不要出现在磁盘文件中: 编写程序，在将行写入磁盘之前将 TAB 扩展到适当数量的空格..。

这里假设你从来不会在一些重要的地方使用制表符，比如在字符串或者字符常量中，但是我从来不这样做: 当它是一个制表符时，我总是使用’t’来代替。

我个人不赞成使用空格代替制表符。对我来说，选项卡是文档布局的字符/机制，而空格用于内容或代码情况下命令之间的划分。

我不得不同意 Jim 的观点，即制表符并不是真正的问题，问题在于人们以及他们如何混合使用制表符和空格。

也就是说，为了约定俗成，我强迫自己使用空间。我重视一致性而非个人偏好。

使用空格。遵循语言约定和你正在从事的特定项目中设置的那些约定。使用一个行程来确保这些约定得到维护。保存格式。全心投入。这将减少团队中的“自行车骑行”。正如我多年前提到的，一致性优于个人偏好！

自行车保护法，也被称为帕金森琐事定律，描述了我们倾向于把过多的时间花在琐碎的琐事上，而把重要的事情置之不理。

标签实际上是一个很酷的发明，它来自于 之后空格。它允许您缩进，而不需要推动空间数百万次或使用假的标签(产生空格)。

我可以大胆地建议你换一个更好的编辑吗？其中一个高科技的，已经发布了大约10年前，那个 显示看不见的字符？(讽刺关闭)

使用空格会导致更多的删除和格式化工作。这就是为什么(以及所有其他知道这一点并且同意我的观点的人)在 Python 中使用制表符的原因。

混合使用制表符和空格是不允许的，也没有争论的余地。这是一团糟，永远不会奏效。

关于 吉姆和托马斯 · 沃特斯在评论中的讨论。

问题在于... 既然制表符和空格的宽度都可以变化——既然程序员不能就任何一种宽度达成一致——为什么制表符要承担责任。

我同意吉姆的观点——标签本身并不邪恶，但是有一个问题..。

有了空格，我就可以控制 “我自己的密码”在世界上每一个编辑器中的样子。如果我使用4个空格——那么无论你在哪个编辑器中打开我的代码，它与左边距都是一样的。对于选项卡，我受制于编辑器的选项卡宽度设置——甚至对于我自己的代码也是如此。我不喜欢这样。

因此，尽管空格确实不能保证一致性——它们至少让您可以更好地控制自己的代码在任何地方的外观——这是制表符所不能做到的。

我认为不是程序员编写代码的一致性——而是编辑器显示代码的一致性——使得空格更容易实现(和强加)。

除了已经提到的所有其他原因(一致性，从不混合空格和制表符等) ，我相信还有一些其他原因需要注意4个空格约定。这些只适用于 Python (也可能适用于其他有缩进含义的语言)。选项卡在其他语言中可能更好，这取决于个人喜好。

1. 如果一个编辑器没有显示制表符(这种情况会发生，取决于配置) ，另一个作者可能会认为你的代码使用4个空格，b/c 几乎所有公开可用的 Python 代码都使用4个空格; 如果同一个编辑器恰好有4个制表符宽度，可能会发生讨厌的事情——至少，这个可怜的人会因为一个缩进问题而浪费时间，这个问题本来很容易通过坚持约定来避免。所以对我来说，最重要的原因就是要一致地避免 bug。

2. 重新定义哪个更好，制表符还是空格，人们应该问制表符的优点是什么; 我看到过很多赞扬制表符的帖子，但几乎没有令人信服的论据; 像 emacs，vi (m) ，kate，... ... 这样的好编辑器根据代码的语义做适当的缩进——即使没有制表符; 同样的编辑器可以很容易地配置为在退格处取消缩进等。

3. 有些人在决定代码外观/布局的自由度方面有很强的偏好; 其他人则重视一致性而不是这种自由度。Python 通过命令将缩进用于块等，极大地降低了这种自由度。这可能被看作是一个 bug 或者一个特性，但是选择 Python 也会带来一些问题。就我个人而言，我喜欢这种一致性——当开始为一个新项目编写代码时，至少布局接近我所习惯的，所以相当容易阅读。几乎总是这样。

4. 使用空格进行缩进允许使用“布局技巧”，这可能有助于理解代码; PEP8中列出了一些例子; 例如。

   foo = long_function_name(var_one, var_two,
   var_three, var_four)
   
   
   # the same for lists
   a_long_list = [1,
   2,
   # ...
   79]
   
   
   # or dictionaries
   a_dict = {"a_key": "a_value",
   "another_key": "another_value"}
   

   当然，以上内容也可以写成

   foo = long_function_name(
   var_one, var_two,
   var_three, var_four)
   
   
   # the same for lists
   a_long_list = [
   1,
   2,
   # ...
   79]
   
   
   # or dictionaries
   a_dict = {
   "a_key": "a_value",
   "another_key": "another_value"}
   

   然而，后者需要更多的代码行，而且有时认为更少的行更好(b/c 你在一个屏幕上得到更多)。但是，如果您喜欢对齐，那么空格(最好由优秀的编辑器辅助)在某种意义上比制表符在 Python 中给予您更多的自由。[好吧，我猜有些编辑器允许你做相同的 w/tab;)-但是对于空格，它们都可以... ]

5. 回到每个人都有的论点-PEP 8规定了(好的，强烈推荐)空格。当然，如果来到一个只使用制表符的项目，您几乎没有选择。但是由于建立了 PEP 8约定，几乎所有 Python 程序员都习惯了这种风格。这使得找到一个被大多数程序员接受的风格的共识变得非常非常容易... 否则，让个人在风格上达成一致可能会非常困难。

6. 帮助实施风格的工具通常不需要额外的努力就能意识到 PEP 8。这不是一个很好的理由，但它只是很好的东西工作出来的盒子。

注意，选项卡的使用混淆了 PEP 8的另一个方面:

将所有行限制为最多79个字符。

假设，你使用2的制表符宽度，我使用8的制表符宽度。你写你所有的代码，使你最长的行达到79个字符，然后我开始工作，你的文件。现在我有了难以阅读的代码，因为(正如 PEP 指出的) :

大多数工具中的默认包装会破坏代码的可视化结构

如果我们都使用4个空格，它总是相同的。任何编辑器可以支持80个字符宽度的人都可以轻松地阅读代码。注意: 80个字符的限制本身就是一场神圣的战争，所以我们不要在这里开始。

任何不糟糕的编辑器都应该有一个选项，可以像使用制表符一样使用空格(插入和删除) ，所以这实际上不应该是一个有效的参数。

我的猜测是，大多数 Linux 文本编辑器默认情况下使默认值看起来大得离谱。我想不出还有什么更好的理由使用空格而不是制表符。

好吧，我想说在 PEP 8中没有这样的“建议”。这是一个建议，因为他们不会禁止你写制表符，但因为代码必须以最标准化的方式编写，我们必须使用空格。

也就是说，如果我是编写标准指南的人，我会推荐选项卡，因为它们是缩进代码的一种现代且更实用的方式。

最后，我要强调，我是 一点也不鼓舞人心任何人使用制表符，相反，我说的是，我们所有的 应该使用空格在 时尚指南所述。