在编写python编程时，我总是使用制表符进行缩进。但是我在这里遇到了一个问题，有人指出大多数Python程序员使用空格而不是制表符来最小化编辑器到编辑器的错误。

这有什么区别？对于python，为什么要使用空格而不是制表符呢？或者根本不是真的？

我应该切换编辑器来立即插入空格而不是制表符，还是像以前那样继续？

厌倦了追寻压痕印刷错误(8个空格？不，7 oops 9…)我将源代码切换为"仅标签"。

1制表符==1缩进级别，完全停止

要点是：如果要将缩进显示为4、8或pi/12字符宽度，只需更改文本编辑器中的设置，就可以避免代码混乱。

(就个人而言，我使用4个字符宽度的标签…但有些人更喜欢3或8个空格，甚至使用可变宽度字体。)

因为pep-8告诉我们使用空格。

耶和华如此说，你要用四个字刻字。不多不少。四个是你要缩进的空格数，四个是你要缩进的空格数。你不可缩进八个，也不可缩进两个，除非你接着前进到四个。标签就在外面。--乔治布兰德尔

使用一个显示制表符的编辑器(就这点而言，所有空格)。你在编程，而不是写文章。

我使用标签。在标签中没有一个空格错误的空间(如果你能看到的话)。问题是人们使用不同的编辑器，世界上唯一常见的事情是：tab==indent，如上所述。一些家伙进来时把tab键设置成了错误的空格数，或者是手动操作，弄得一团糟。选项卡并使用真正的编辑器。(这不仅仅与PEP相反，它是关于C/C++和其他空白不可知语言的)。

/从Soapbox下来

我在空格上使用制表符的主要原因是退格键。如果我在一行上，我想用退格键删除这一行上的一个缩进，如果是空格，我必须用退格键4x；但是，如果是制表符，我只需要敲击它一次。

我将继续使用制表符，因为在将制表符转换为空格之前已经说过类似的内容，但这并不是相反的方式。

我在想我要写一个简单的程序，将带有空格的代码转换为带有制表符的代码，因为我讨厌空格。他们把我逼上了墙！

哦！使用箭头键左右移动，在空间上总是让人头疼。

更新：Sublime Text 3现在用退格键删除了一个完整的软标签；不过，箭头键导航仍然很繁琐。

更新：我现在使用vscode并为它编写了tabsanity扩展来解决退格键、删除键和箭头键导航问题。

最"Python式"的方法是每个缩进级别使用4个空格。但是，python解释器将识别空格或制表符。唯一的Gottcha是你不能混合空格和制表符，选择一个或另一个。也就是说，规范建议使用空格，大多数开发人员都使用空格，所以除非您有一个非常好的理由不使用空格，否则我建议使用空格。

据我所知，这里是选项卡和空格的优缺点。

选项卡的优点：

• 减少缩进、取消缩进和遍历缩进所需的击键次数。(即使您的IDE有一些空间缩进的巧妙性，它也永远不会像标签那样好。)
• 不同的程序员可以根据需要使用不同的选项卡显示大小。
• 不能将光标"放在"缩进字符内。例如，假设您正在复制一些行，使用制表符，您可以在行首附近模糊地单击以开始选择，您将获得所有第一个制表符。如果使用空格，则很可能会错过第一个空格字符，除非您击中它与边距之间的小目标。与从行中删除缩进类似，如果光标位于四空格缩进字符的中间，大多数编辑器无法很好地处理按退格键。它通常会删除一个空格。有了标签，它可以按预期工作。
• 与其他语言的一致性，所以你不必设置你的编辑器使用，例如标签的C++/Java和Python的空间。
• 错误的缩进可能更明显(即，额外的标签比额外的空间大得多)。

标签的缺点：

• 大多数Python程序员都使用空格，所以您将违反约定。
• 使用空格对齐多行语句比使用制表符更容易。您可以使用制表符进行缩进，使用空格进行对齐，但在Python中这似乎有点危险！

有些人夸大了一些非问题：

我已经开始使用空格来与其他Python代码保持一致，但老实说，我可能会改回制表符，这已经够令人沮丧的了。很大程度上取决于您的IDE的功能，但是在我的经验中，没有任何一种IDE对空间缩进的支持比仅仅使用制表符更好。

所以除非你真的不喜欢和大多数人不一致(大概不是全部！)python代码，使用制表符并打开空白可视化和缩进突出显示(如果可用)。对我来说，最大的原因是容易选择和(相当重要的IMO)减少击键。有些惯例是愚蠢的。

更新：我发现世界上有一个编辑器(不包括像vim这样的胡说)可以正确地支持空格作为缩进：atom。它有一个名为"原子制表符"的选项，使4个空格在所有方面都表现得像一个制表符(除了可以调整大小)。不幸的是，Atom是一个相当缓慢和臃肿的编辑器，但这是一个很好的功能，如果您被迫使用空格，它可能是一个不错的选择。希望有一天其他编辑会开始支持它。这是vscode的问题。

我最近看到一篇题为python:Myths about indentation的文章，讨论了这个问题和相关的问题。本文有充分的理由建议在编写python代码时使用空格，但肯定有分歧的余地。

我相信大多数Python程序员只使用空格是真的。

使用一个编辑器，当您按tab键时，可以将空格插入到制表位，而不是插入 字符。然后忘记它。

我在使用空格而不是制表符时遇到的唯一不便是，您不能轻易删除缩进级别；您必须删除四个空格而不是一个制表符。

您可以混合制表符和空格…但是一个标签被认为是8个空格的缩进，所以除非您的编辑器将标签设置为8个空格，否则在混合它们时会遇到麻烦。

标签规则。嵌套循环的参数相同，您希望将外部循环"返回"1级。提示：如果要将旧的充满空格的python代码转换为制表符，请使用http://www.textpad.com/add ons/上作为可执行文件提供的tabout实用程序。

我非常强烈地感觉到，无论历史惯例如何，制表符只是一个更好的选择，应该在以后编写的每一行Python代码中替换空格。就像踢出一个无能的暴君。我的理由是：作为核心价值的简单性。使用两个或四个字符来完成一个的语义任务？在我看来，没有比传统更合理的理由了。

当您在文件中混合了缩进时，会出现编辑器到编辑器的错误。这产生如下：一个代码块用4个空格缩进，然后一个缩进级别"in"，用制表符缩进。现在做这个的异教徒(混合标签和空格)有了它，所以他的标签也是4个空格，所以他看不到问题，而python看不到问题。

现在我们的受害者来晚了，他的标签设置为8个空格。现在，我们的受害者认为代码看起来很糟糕，并通过删除一个缩进级别来修复它，这使得代码看起来仍然是两个缩进级别，但实际上是一个级别。在这一点上，所有的地狱都被释放了。

这里的教训是，您永远不应该混合制表符和空格。如果您坚持这样做，那么很容易将代码重新插入空格或制表符中，而不管您个人使用的是哪个。确保不混合制表符和空格的最佳方法是始终使用python和-tt，这在制表符和空格混合时会产生错误。

至于制表符和空格，我个人使用制表符来区分缩进和外观-当代码使用制表符缩进时，更改代码外观比使用空格缩进要容易得多。我知道这与99%的Python程序员所做的相反，但这是我个人的偏好，而且在任何情况下都很容易将选项卡文件转换为间隔文件。相反的情况并不总是正确的，因为你可以不小心在字符串中打出4个空格，等等。

当我第一次学习Python时，我对重要的空白概念有点反感，因为使用它的大多数语言都是不灵活的。也就是说，我对Python理解各种缩进样式的能力印象深刻。在考虑新项目使用什么样式时，我认为记住两件事很重要。

基本上，有一个定义选项卡宽度的变量(可以通过在源文件顶部包含注释来更改该变量)。当python遇到制表符时，它会增加到下一个制表符宽度倍数的缩进距离。因此，如果在文件左侧输入一个空格，后跟一个制表符，则制表符宽度的下一个倍数为8。如果一个标签本身被输入，同样的事情也会发生。

这样，如果编辑器配置正确，使用制表符，甚至混合制表符和空格都是安全的。只要将编辑器的制表位设置为与python制表位宽度声明相同的宽度(如果没有，则设置为8)。除非在文件中指定制表宽度，否则使用制表宽度不是8个空格的编辑器通常是一个坏主意。

我遇到过成功地混合使用制表符和空格的项目。基本上，空格用于缩进小部分，其中缩进部分中的事实相对不重要；而制表符用于吸引读者对大型结构特征的注意。例如，类从一个选项卡开始，该选项卡使用两个空格对函数内部进行简单的条件检查。

当处理大的文本块缩进多个级别时，选项卡也很有用。当您退出3-4级缩进时，使用适当的制表符要比使用适当数量的空格容易得多。如果项目不使用PEP 8推荐的样式，最好将样式指南写入某个文件中的某个位置，以便缩进模式保持一致，并且其他人可以明确地阅读如何将其编辑器配置为匹配。

另外，python 2.x还可以选择-t来发出关于混合制表符和空格的警告，而-tt来发出错误。这只适用于同一范围内的混合选项卡和空格。python 3假设-tt，据我所知，无法禁用该检查。

我主要是C++程序员，但有时我的项目包括少量的Python。我使用标签来缩进我的C++代码。这意味着我有三个选择：

对于我的项目，我通常使用选项3。

经验和PEP-8都清楚地得出结论，应避免混合空间和TABs。如果你想混合使用它们，你必须在IDE中可视化空白——但是你失去了Python缩进的优势，使得范围很容易被看到。在IDE中可视化空白会使显示混乱。

如果它是制表符或空格，那么它必须是空格，原因很简单：可以切换几乎所有的IDE和文本编辑器，以自动用空格替换制表符，但事实并非如此。

尽管有IDE可以自动将行中的前导空格转换为制表符，但这最终会导致制表符和空格的混合。考虑多行语句，例如带有大量参数或文档字符串的函数调用。虽然"ascii-art"也要避免，但很容易发生的意外是，在前面的标签后面留下了一个空格。

其他答案带来了几个支持标签的论点：

• 打击TAB更有效。当然，这是正确的，但是当按下tab键时，所有文本编辑器都允许立即插入所需的空格数。
• 当只需要删除一个制表符而不是2/3/4/8空格时，缩进/取消缩进更容易。是的，但大多数文本编辑器都允许自动执行此操作：块选择、缩进/取消缩进是编程编辑器的基本功能，如注释/取消注释。如果文本编辑器没有实现这一点，那么它至少应该有一个易于使用的宏功能，用它可以实现相同的事情。
• 不同的程序员喜欢不同的缩进宽度。这是事实，而且只使用TAB的明显优势。问题在于与其他个人和/或团队的互动。为了在现实世界中发挥作用，每个人都必须同意只使用TABs。既然这还没有发生，它也不会起作用。在一个真实的场景中，有一系列的编码指导原则，不管怎样，项目都同意，而且缩进方法当然是其中之一——即使在其他编程语言中，在视觉层面上的含义是"唯一的"。

imho，这里缺少大多数(如果不是全部)答案的主要点是团队或个人之间的交互，特别是在参与者列表一开始就不知道的情况下。当代码满足代码时，要么所有人都必须使用制表符，要么所有人都必须使用空格。如果没有最终遇到功能问题，就不能将其混合。人并不完美。工具并不完美。这就是为什么imho我们根本不应该使用TAB。

没有格雷格已经在他的答案中提供的链接，答案是不完整的：python：关于缩进的神话

每个人对应该缩进多少代码都有不同的偏好。假设您与某人共享代码，他或她对缩进有不同的偏好。如果缩进是在制表符中，您的朋友总是可以在其编辑器设置中更改制表符宽度。但是，如果缩进是在空格中，那么如果您的朋友想要将其设置为他们的首选项，那么他/她实际上必须更改源代码。然后，当你得到你朋友的改变，你可以决定改变它回到你的喜好。在这种情况下，您要么要处理前后更改缩进级别的繁琐问题，要么一个人必须在缩进级别中采用另一个人的偏好。如果您和您的朋友都使用制表符，那么您有不同的首选项是没有问题的，因为您可以在代码保持不变的同时看到不同的缩进级别。这就是为什么在我看来，在所有编程语言中，制表符都比缩进空格好。

使用空格而不是制表符的问题是文件大小变得非常大…例如，在将空间替换为选项卡时，500 KB的缩进文件空间可以减少到200 KB，这就是为什么我总是使用选项卡的原因。

较小的文件大小意味着更快的加载、编译、执行(在某些情况下)等。

对我来说，使用空格没有意义，但是如果有人使用的编辑器与制表符有问题，那么他们可以将" "替换为""或""或其他内容…

有一种情况是选项卡根本不起作用，即：根据您使用的编码样式，您可能需要将一些代码行缩进到一个空格精度，即：

在这种情况下，使用纯制表符根本不起作用；使用制表符进行主缩进和使用空格进行子缩进将起作用，但这将违反不混合这两者的硬规则。

但是，在使用避免类似于上述代码示例的情况的编码样式/约定文档时，情况并非如此。

除了已经列出的所有论点之外，我发现这一个相当重要(从有关缩进的神话中)：

Also, tabs often get destroyed or wrongly converted during copy&paste operations, or when a piece of source code is inserted into a web page or other kind of markup code.

另一个反对标签的论点(强烈的环境特定性)是，它们有时在电话键盘上丢失。在可能的情况下，可以通过安装备用键盘来解决这一问题。

关于标签的一个论点，似乎还没有人提到，1个标签是1个字符(文件中是0x09，1个字节)，而4个空格是4个字符(文件中是4乘以0x20，4个字节)；因此，使用空格会导致4倍的空间浪费。

为了总结这个不连贯的论点列表，我想在第7012期中引用蒂姆·彼得斯的回答：标签比缩进的空格更好：

The Python"spaces only" standard is for
distributed code. Years of early experience taught us beyond doubt that
tabs caused endless problems for shared code (...)

我认为有一个解决方案可以同时拥有：

在记事本+中，转到"首选项"-->"选项卡设置"，然后从右边的列表中选择"python"。然后确保"制表符大小：4"，并选中"用空格替换[制表符]"。在这种情况下，您可以简单地使用tab键进行缩进，但记事本++实际上会将其转换为4个空格。

How does that make a difference?

默认情况下，某些编辑器配置为用一组空格字符替换单个制表符，但有些则不是。如果每个人都使用空格，可以忽略默认编辑器设置中的差异。

Are there other reasons why one would use spaces instead of tabs for Python? Or is it simply not true?

是的，在我面前的许多答案都指出了其他的正当理由。"然而，PEP-8"说的不是这些原因之一。这源于一个自生自灭的神话，即PEP-8是所有Python代码的编码标准，而实际上它只是标准的一组Python库的编码标准。有人声称PEP-8被广泛接受，也有人声称大多数Python程序员使用空格而不是制表符。我想要求这些主张的证据，因为这个网站上的投票数清楚地表明标签是群众的首选。我觉得很不幸的是你接受了"pep8 says so"作为你问题的答案，而事实上还有很多其他的答案可以解释空格和制表符的相对优缺点。

Should I switch my editor to insert spaces instead of tabs right away or keep on going like I used to?

这取决于，最后一个问题的答案是，我认为我可以在哪里为这个线程添加一些值。imho，无论使用何种语言，要使用的最佳编码标准取决于您所处的环境：

• 如果您开始使用已经存在的代码库：不要太困难，请遵循现有的编码标准
• 如果一个团队从头开始一个新项目：讨论，在开始时作为一个团队决定一个编码标准，并坚持下去
• 如果你要独自去：做任何能让你感到最快乐和最有成效的事情

那么你处于哪种情况下呢？

最后，为了明确我的立场，对于我自己的单独项目，我使用标签，因为标签对我更有意义，而且我对标签更有效率。

这是截至2017年7月的PEP 8：

这句话似乎没有其他选择的余地。

但这不仅仅是Pep 8告诉我们的，几句话之后：

在上面，第一条语句表示对空格的偏好，第二条语句承认存在用制表符缩进的代码，并且这种偏好也适用于某些编码人员。

因此：PEP 8具有制表位缩进公差。但它不允许制表符和空格混合缩进，因为缩进本身是强制的，所以可以理解。

值得一提的是，Google的python编码风格也遵循4空间规则。

还有其他各种各样的论点和理由支持制表符或4-空格。

如果您在执行PEP 8的公司工作，或者定期与遵循PEP 8的其他人共享您的代码，那么常识要求4个空格。我是(也许，)用于C/C++的选项卡。但是有了适当的IDE，差异就变得很小了。

使用空格代替制表符，唯一的原因是你会赚更多的钱：)

参考：使用空格的开发人员比使用制表符的开发人员赚更多的钱(StackOverflowBlogPost)。

因此，我在这里阅读所有的回答，想知道我如何能够遵守PEP-8，而不必反复敲打退格键来消除缩进，我看着我的罗技游戏键盘，它所有的华丽宏按钮和一个灯泡都在我的脑海中亮着。

我打开Logitech的软件，为选项卡按钮旁边的按钮定义了几个宏，问题就解决了。

一个按钮添加四个空格，另一个按钮进行四次退格。太神了。真是太棒了。用我的小指也很容易按下按钮。

看，看看这个：""<--四个空格！只需按一下按钮！如果我能给你看退格，我也会这样做。去买一个Logitech G105键盘，你所有的问题都会消失！

我认为使用空格的一个主要好处是，您消除了在大量外部工具中呈现源代码的可变性，这些外部工具必须与源代码进行交互，而不是选择编辑器以及它们在其中配置的任何设置。

作为一些具体的例子，可以考虑在Visual Studio代码的工具提示中，或者在比较或WinMerge等diff工具中，在性能或代码覆盖工具等工具中呈现python docstring。基本上，所有这些不同的其他接口工具对于如何解释选项卡都有不同的设置，而且有时会很烦人。在你可能潜入或潜入的工具集中，迷失方向去发现完全不同的东西或被推离屏幕。

简言之，您在源代码中定义了对齐，而不是为您的工具库中的工具套件制定统一的配置。由于字体的定义，而不是第三方的制表符呈现实现/配置，因此空间严格解释为单空间字体，以便在整个工具范围内实现可靠和一致的对齐。

另一个角度是复制前导标签源以在终端上运行，在终端上标签字符可能触发无意中完成的标签。例如，如果复制以下python源代码(用作缩进的制表符)，

您可能会看到如下内容(在Visual Studio代码的集成终端上看到)…

(顺便说一句：我想知道，这种对工具一致性的观察是否是一个敏锐的开发人员的一种歧视性思维的标志，他们希望命令世界，这可能暗示在堆栈溢出中发现的工资差异。)

我喜欢标签，但它与我喜欢的另一个规则不兼容：80列的限制。

如果选择4个空格制表符并插入10个制表符，则剩余40个字符以满足80列的限制。如果另一个编码人员喜欢8个空格制表符，则同一行将显示为120个字符长，并且不会显示为有效的80列行！

如果要定义80列的限制，则必须为选项卡选择长度。在这种情况下，有x个空格或长度为x的制表符并不能真正起作用。

编辑：相关线程：使用制表符而不是空格时是否保持最大行长度？

我刚开始，但我发现使用制表符比使用空格容易得多，而且不理解PEP-8只提倡空格。Sublime Text 2可以很好地可视化带有灰白色垂直虚线的选项卡，虽然有一些情况是我混合了一两个空格来排列列表或字典的元素，但我没有经历过这样一种情况，那将是有害的事情。

人们将在同一代码上使用不同的编辑器。这些编辑器将以不同的方式在屏幕上表示一个选项卡。如果您使用的编辑器将选项卡表示为4个空格，如果您使用"\t "缩进第一行，使用"\t\t"缩进第二行，则它们看起来像是处于相同的缩进级别：8个空格。

Python解释器不知道您的编辑器，它必须将选项卡解释为一定量的缩进。实际上，它将选项卡解释为8个空格，因此它将看到不同于预期的缩进级别：第一行12个空格，第二行16个空格。你被烤了。

我最近从标签切换到空格，以符合PEP 8。

我以前喜欢标签有两个原因：

…但当我意识到Pep 8变得多么重要后，我还是换了。如我所见，标签上方的空格的主要价值是简单性——你所看到的就是你所拥有的。以及PEP 8合规性。我想出了一个VIM规则，可以打开python文件的空间，留下makefile的标签。

最近不得不处理混合了空格和制表符的现有代码，这真是令人困惑。

当你混合的时候(你真的不应该这样做，但不幸的是它确实存在)，看起来"1 tab==1 indent level"不是真的。

以下面的示例(使用python 2.7进行了尝试)：

这里，在def add(...)之前有4个空格(1个识别级别)，在self.total += x之前有8个空格(2个缩进级别)，在if self.total > 10之前有一个选项卡。

但是，由于这段代码可以工作，所以单个选项卡的行为就像两个缩进级别。相反，如果用4个空格(单个缩进级别，即类中的def所在的位置)替换所有选项卡，则在return之前会出现意外的缩进错误，因为它不再位于def块中。

对于将选项卡显示为4个字符的编辑器来说，这真是令人困惑。当然，可以对其进行配置，但这也会影响源代码查看器(如Github等)，因为在这些浏览器中，配置起来并不一定容易(或者可以立即看到您需要这样做)。

选项卡V.S.空间行为始终取决于编辑器：

• 如果您的编辑器在每次按Tab键时自动插入空格，它将插入正确数量的空格，以便另一个编辑器显示完全相同的样式。
• 如果您的编辑器不使用制表符，则始终有可能不会注意到使用空格而不是制表符的行(尤其是在项目中使用其他编辑器时)。

两者都有各自的缺点。底线是在制表符和空格之间需要有一个任意的选择，但是它们不应该混合在一起。因为您永远不知道代码以后将如何读取和使用，所以有一个影响所有Python编码人员的约定是很好的。PEP-8说的是空格，就这样吧。

重要的是不要用Java的方式去做：

Four spaces should be used as the unit of indentation. The exact
construction of the indentation (spaces vs. tabs) is unspecified. Tabs
must be set exactly every 8 spaces (not 4).

对。。。Java世界中1个标签= 2个缩进级别！谢天谢地，它在编译方面没有同样的意义。

(对某些人来说)更模糊标签方面的论点：我被告知标签对盲人的屏幕阅读器更有效。

我使用两个空格缩进和一个编辑器(KWRITE)，当我按Tab键时，它插入空格而不是制表符。